Re: [RFC] file extents for EXT3

[Rob Landley]

On Monday 11 August 2003 12:23, Jeff Garzik wrote:

> Of course, the other alternative is to rename ext3 to "linuxfs", add a
> "no journal at all" mode, and remove ext2.  But I prefer my "ext4"
> solution :)

Well, embedded developers probably like the smaller driver.  Of course they 
can always use minixfs. :)

Something I've wondered about for a while:

With the ability to place a journal on another block device, you could 
theoretically throw the journal on a 1 megabyte ramdisk, and more or less 
degrade ext3 to ext2 that way (as long as you made sure to fsck the heck out 
of it on the way back up each time).

Beyond that, why is the minimum journal size 1 megabyte?  (Having to waste a 
megabyte of ram on a 4 megabyte filesystem is kind of annoying.  And yes, 
buildroot on uclibc with busybox can give you quite a lot of functionality in 
4 megabytes)  In theory, if the journal could be crushed down small enough, 
then the ramdisk solution isn't so bad, although needing to compile in the 
ramdisk and set it up is a bit clumsy, better still if the journal code could 
just bounce the blocks off of a small internal ram buffer.  (Personally, I'll 
live with the redundant in-memory copies; still faster than the disk by a 
long shot.)

Beyond THAT, ext2 could be considered ext3 with a "no journal" flag 
(automatically supplied when the mount is read only, for example).  Last time 
I did an embedded device, I had to stick both ext3 in (for the runtime data 
partition) and ext2 in (for the initrd that loopback mounted the firmware 
image, which was a zisofs containing the root partition).  Initramfs 
addresses this particular annoyance, but still leaves a problem creating a 
bootable CD that's going to install to ext3...

Having to compile two filesystems into the kernel with basically the same 
on-disk layout is kind of annoying, but ext3 simply isn't a good fit for a 
small ramdisk or for read-only media.

I realise that ext3 was kept separate from ext2 because ext2 should be 
uber-stable, but the argument there is that people who care about keeping 
their writeable data safe are intentionally not using journaling.  (Meanwhile 
we're completely redoing the block layer underneath them, and both the SCSI 
and IDE subsystems, and raid, but all those are obviously FAR less likely to 
do strange things to their data behind their back than the filesystem is... 
:)

Oh well.  Too late to worry about it for 2.6 anyway... :)

Rob


-
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/