Re: [PATCH] SMP race in ext2 - metadata corruption.

[Pavel Machek]

gHi!

> >     It's not exactly "kernel-based fsck". What I've been talking about
> >     is secondary filesystem providing coherent access to primary fs
> >     metadata.  I.e. mount -t ext2meta -o master=/usr none /mnt and
> >     then access through /mnt/super, /mnt/block_bitmap, etc.
> > 
> > Call me stupid --- but what exactly does the above actually achieve?
> > Why would you do this?
> 
> Coherent access to metadata? Well, for one thing, it allows stuff like
> tunefs and friends on mounted fs. What's more useful, it allows to
> do things like access to boot code, which is _not_ safe to do through
> device access - usually you have superblock in vicinity and no warranties
> about the things that will be overwritten on umount. Same for debugging
> stuff, IO stats, etc. - access through secondary tree is much saner
> than inventing tons of ioctls for dealing with that. Moreover, it allows
> fsck and friends to get rid of code duplication - while the repair
> logics, etc. stays in userland (where it belongs) layout information
> is already handled in the kernel. No need to duplicate it in userland...

OTOH with current way if you make mistake in kernel, fsck will not
automatically inherit it; therefore fsck is likely to work even if
kernel ext2 is b0rken [and that's fairly important]

> Besides, with moving bitmaps, etc. into pagecache it becomes trivial
> to implement.
> 
> BTW, we have another ugly chunk of code - duplicated between kernel
> and userland and nasty in both incarnations. I mean handling of the
> partition tables. Kernel should be able to read and parse them -
> otherwise they are useless, right? Now, we have a bunch of userland

No. You might want to see (via fdisk) partition table, even through
*your* kernel can not read it.
								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.