Re: [PATCH 1/5] Forking ext4 filesystem from ext3 filesystem

[Jeff Garzik <jeff@garzik.org>]

Andrew Morton wrote:
> On Thu, 10 Aug 2006 11:51:34 -0700
> Badari Pulavarty <pbadari@us.ibm.com> wrote:
> 
>> Andrew Morton wrote:
>>> Also, JBD is presently feeding into submit_bh() buffer_heads which span two
>>> machine pages, and some device drivers spit the dummy.  It'd be better to
>>> fix that once, rather than twice..  
>>>   
>> Andrew,
>>
>> I looked at this few days ago. I am not sure how we end up having 
>> multiple pages (especially,
>> why we end up having buffers with bh_size > pagesize) ? Do you know why ?
>>
> 
> It's one or both of the jbd_kmalloc(bh->b_size) calls in
> fs/jbd/transaction.c.  Here we're allocating data to attach to a bh which
> later gets fed into submit_bh().
[...]

I respectfully submit that this sort of urge to clean up all the 
narstiness (a local term) in ext3 is _precisely_ the reason why we need 
ext4 in the tree ASAP.

Once people start pushing a large volume of changes into ext[34], the 
"obvious cleanups" start popping up.  Look at the ratholes we are 
_already_ diving down, in this thread, trying to clean up ext3 before 
the copy.

ext4 will exist precisely to enable these sort of rapid cleanups.  If 
obvious stuff starts popping up, the cleanups can go in immediately 
without worry of destabilization.

Just let ext3 sit.  Other filesystems use submit_bh(), brelse(), etc. 
If ext3 is to stop using those, let it be when others stop using them as 
well.

ext4 is the devel tree.  ext3 is the stable tree.  Just go ahead and "cp 
fs/ext3 fs/ext4" immediately, otherwise the cleanups will pile up, and 
the branch will take place a year from now.

	Jeff, still waiting for submit_bio() to be used in fs's :)