lkml.org 
[lkml]   [2006]   [Jun]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Ext2-devel] [RFC 0/13] extents and 48bit ext3
    On Jun 09, 2006  21:21 -0400, Valdis.Kletnieks@vt.edu wrote:
    > On Fri, 09 Jun 2006 17:21:08 MDT, Andreas Dilger said:
    > > You mount with the new kernel without "-o extents", and find files with
    > > extents "lsattr -R /mnt/tmp | awk '/----e / print { $2 }'", copy those
    > > files, mv over old files, unmount.
    >
    > How do you "copy those files" when you don't have extent support at that
    > point? Remember - the whole problem here is that if you don't have
    > extent support, you can't read the file, it's backward-incompatible.
    > (If you *are* able to read the file even without extents, then this whole
    > thread is total BS).

    The "-o extents" mount option only affects new files that are created
    while that option is enabled. It doesn't affect existing files (even if
    they are modified while "-o extents" is set). It also doesn't affect any
    new files after "-o extents" is removed. Also, directories will not
    be extent-mapped, because their allocation pattern doesn't mix well with
    extent-mapped files (i.e. they are mostly single-block allocations).

    Files that are created with "-o extents" are of course only readable with
    a kernel that supports it. To be safe, the whole filesystem is marked
    with an EXT3_FEATURE_INCOMPAT_EXTENTS flag when the first extent file
    is created so that users don't inadvertently get strange errors while
    accessing the inodes marked with EXT3_EXTENT_FL with an old kernel.
    New kernels that understand INCOMPAT_EXTENTS of course can access extent
    and non-extent files equally well.

    In an emergency it would also be possible to remove the INCOMPAT_EXTENTS
    filesystem flag and access all of the non-extent files, but this would
    risk filesystem corruption if any of the extent files were modified or
    unlinked, as that is the only indication older kernels have of this change.

    So, to answer your question, if you _really_ want to get rid of extents
    on a filesystem, you mount the filesystem with INCOMPAT_EXTENTS on a new
    kernel that supports extents, but without -o extents so new files will
    use the old block-map layout, so if "orig-file" is an extent-mapped file:

    cp /mnt/tmp/orig-file /mnt/tmp/temp-block-mapped-file
    mv /mnt/tmp/temp-block-mapped-file /mnt/tmp/orig-file

    and now /mnt/tmp/orig-file is no longer extent-mapped. Do this for all
    the extent-mapped files, unmount, use "debugfs -w -R 'feature ^extents' {dev}"
    and your filesystem is mountable with any old kernel.

    No, it's not quite as easy as ext3 journal recovery->ext2 mounting,
    but then again "-o extents" isn't something that happens automatically
    (at least not for a couple of years, and hopefully distros will be smart
    enough never to do this for filesystems like /boot or / that are critical
    for mounting on a wide variety of kernels. Besides which, we don't want
    to have to teach GRUB about extent-mapped files. Concievably, if this
    becomes an issue then it should be possible to add a flag to inodes and
    parent directories to add a "no extents" flag that is inherited by new
    files that should never be extent mapped.

    Cheers, Andreas
    --
    Andreas Dilger
    Principal Software Engineer
    Cluster File Systems, Inc.

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

    \
     
     \ /
      Last update: 2006-06-10 04:11    [W:4.217 / U:0.856 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site