[lkml]   [2002]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 12/16] fix race between writeback and unlink
    Linus Torvalds wrote:
    > On Tue, 4 Jun 2002, Andrew Morton wrote:
    > >
    > > There's a patch at
    > >
    > > which provides a simple `relocate page' ioctl for ext3 files.
    > That's a good start, but before even egtting that far there is some need
    > for a way to get a picture of the FS layout in a reasonably fs-independent
    > way.
    > Sure, bmap() actually does part of this (the "where are my blocks" part),
    > but right now there is no way to query the FS for the "where can I put
    > blocks" part.

    Jeff Garzik was working on that a while back - a separate filesystem
    which provides a "metadata view" of a real filesytem. So you can
    poke around and find all these things out. In theory, different
    filesystems should be able to offer the same view.

    > You can do it with direct disk access and knowledge of the FS internals,
    > but it should not be all that hard to add some simple interface to get a
    > "block usage byte array" kind of thing (more efficient than doing bmap on
    > all files, _and_ can tell about blocks reserved for inodes, superblocks
    > and other special uses), which together with a user-level interface to
    > "preallocate" and your "relocate page" should actually make it possible to
    > make a fairly FS-independent defragmenter.

    The e2fsprogs package includes a `libe2fs' library which offers
    APIs for accessing the fs internals. It's exactly what you
    say - direct disk access and knowledge of internals. So
    that plus the try_to_relocate_page() ioctl is a shortest-path
    route to a defragmenter for ext3, and only ext3. I wasn't
    aiming very high here ;)

    A totally different way of performing defrag could be to
    copy the entire fs from one partition to a different one,
    with kernel support for providing coherency while the copy
    is in progress. It's basically a union/translucent mount
    with COW. Swizzle the backing blockdev, drop the disk
    mappings from all incore pages, renumber the inode without
    breaking stuff... (OK, I've talked myself out of it ;/) It's
    not super efficient, and it does require the provisioning of a
    bounce disk, but it would use infrastructure which would be
    useful for other stuff and it is fs-agnostic.

    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:26    [W:0.040 / U:10.568 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site