lkml.org 
[lkml]   [2013]   [Jan]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Tux3 Report: Initial fsck has landed
    On Mon, 28 Jan 2013, Theodore Ts'o wrote:

    > On Sun, Jan 27, 2013 at 10:13:37PM -0800, Daniel Phillips wrote:
    >>> The thing that jumps out at me with this is the question of how you will
    >>> avoid the 'filesystem image in a file' disaster that reiserfs had (where
    >>> it's fsck could mix up metadata chunks from the main filesystem with
    >>> metadata chunks from any filesystem images that it happened to stumble
    >>> across when scanning the disk)
    >>>
    >> Only superficially. Deep thoughts are in order. First, there needs to be a
    >> hole in the filesystem structure, before we would even consider trying to
    >> plug something in there. Once we know there is a hole, we want to
    >> narrow down the list of candidates to fill it. If a candidate already lies
    >> within a perfectly viable file, obviously we would not want to interpret
    >> that as lost metadata. Unless the filesystem is really mess up...
    >>
    >> That is about as far as I have got with the analysis. Clearly, much more
    >> is required. Suggestions welcome.
    >
    > The obvious answer is what resierfs4 ultimately ended up using. Drop
    > a file system UUID in the superblock; mix the UUID into a checksum
    > which protects each of the your metadata blocks. We're mixing in the
    > inode number as well as the fs uuid in in ext4's new metadata checksum
    > feature to protect against an inode table block getting written to the
    > wrong location on disk. It will also mean that e2fsck won't mistake
    > an inode table from an earlier mkfs with the current file system.
    > This will allow us to avoid needing to zero the inode table for newly
    > initialized file systems.

    The situation I'm thinking of is when dealing with VMs, you make a filesystem
    image once and clone it multiple times. Won't that end up with the same UUID in
    the superblock?

    David Lang


    \
     
     \ /
      Last update: 2013-01-29 01:01    [W:2.195 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site