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