Re: [PATCH] Add "-o bh" option to ext3

[Badari Pulavarty <pbadari@us.ibm.com>]

On Tue, 2006-03-14 at 10:47 +0100, Pavel Machek wrote:
> Hi!
> 
> > > > Its not really need for now, but as we try to make "nobh"
> > > > as default option, it would be nice to have a "-obh" fallback
> > > > option - if things go wrong.
> > > 
> > > Docs patch is missing...
> > > 
> > > ...and no, it is not even clear to me what bh vs. nobh does...
> > 
> > Hope this helps.
> 
> Not really, I still am not sure what it does. Is it like "nobh is more
> effective code, and should have exactly zero impact to the user, but
> as it is new, we make it optional"?

I wish, its that easy to say :)

Historically (2.4 and earlier), buffer_head is the primary structure for
doing IO. We also used it as the interface between VFS, helper functions
and filesystem-specific code to pass physical disk block# information.
We also used them to link buffers/pages/data to JBD transactions to
provide ordering guarantees (for various journal modes).

Now (2.6), we no longer use buffer_head as a primary IO descriptor, 
but we still use it for other reasons. In general, buffer_heads are 
evil - eats up low mem, lots of them floating around, bigger code path,
bigger memory foot print, causes TLB/SLB misses, causes fragmentation
etc..

"nobh" option tries to attaching buffer_head to pages to cache disk
block mapping information. Where ever its needed, it uses temporary
(on stack) buffer_head to pass it to lower-level filesystem-specific
code and uses the disk block# mapping info from it - to create bios.
(BTW, since its also used for transaction ordering - we can't support
"nobh" option for all journaling modes).

Now, "zero impact to user ?" - don't know for sure. Since buffer_head
nicely cache disk block mapping information - we save on calls to
filesystem->get_block() when we need this. With "nobh" option, 
we need to do this every time. Especially on filesystems with 
blocksize < pagesize (1k, 2k) - we may need to multiple calls to 
->get_block() to get all the disk block#s for a single page (4k). 
These calls,  *in theory* could end up doing a disk read. All the
benefits of not having buffer_heads may be worth taking this 
overhead ?  Don't know for sure - thats why this is an "option" 
for now :(

Clear as mud ? :)

Thanks,
Badari

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/