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

From: Jeff Garzik
Date: Thu Aug 10 2006 - 16:37:42 EST


Andrew Morton wrote:
On Thu, 10 Aug 2006 11:51:34 -0700
Badari Pulavarty <pbadari@xxxxxxxxxx> 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 :)



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