[lkml]   [2001]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] SMP race in ext2 - metadata corruption.

    > > 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.
    Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
    details at

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:17    [W:0.027 / U:10.792 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site