Messages in this thread | | | Subject | Re: [PATCH] Add "-o bh" option to ext3 | From | Badari Pulavarty <> | Date | Tue, 14 Mar 2006 08:32:03 -0800 |
| |
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/
| |