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/