Messages in this thread | | | Date | Sat, 5 May 2001 23:59:17 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: [PATCH] SMP race in ext2 - metadata corruption. |
| |
On Sun, 6 May 2001, Chris Wedgwood wrote:
> 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...
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 utilities that do the same. Various fdisks, that is. If you look how they work you'll see that on the read side they duplicate kernel code and on the write side... To put it quite mildly, they are not doing it in graceful way. They write relevant sectors to disk and use BLKRRPART to tell the kernel that ti should forget about all partitions on that disk and reread the partition tables. _Not_ a nice thing to do, since creation of new partition out of unused space on /dev/sda becomes an interesting task when your root lives on /dev/sda1. Ditto for destroying a single partition (not mounted/used by swap/etc.) while you have some other partition in use. IWBNI we had a decent API for handling partition tables...
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |