[lkml]   [2006]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] Add "-o bh" option to ext3
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

"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 ? :)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-03-14 17:32    [W:0.057 / U:1.300 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site