> What might be the best way to "defrag" files.
Dump/reload to/from a freshly formatted filesystem
*on a different device*.
> I've noticed a /huge/ speedup when defrag'ing files using the
> following method:
> create a new file in same directory
> use ftruncate to set the new file's size the same as existing file
> copy data from existing to new file
> close both files and rename new file to the old file (atomic replace)
That is a silly, random way.
A more plausible method that I have used in bad cases where a
quick fix was needed is:
- Create enough 1GB (or 100MB or whatever) "dummy" files to
fill a partition.
- Check the number of fragments or transfer rate of each file.
- Delete all those that have a low transfer rate and/or high
number of fragments.
This means that the files that remain "soak up" the bad
fragmented part of the "free list", and further allocations will
end up in the "good" unfragmeneted part of the free list.
If enough space remains one could copy all existing files over
gain within the same filesystem, but of course same device/same
filesystem copy is going to be rather slow, and dump/reload has
the advantage of creating a backup copy, which is very important.
> I recently did this to a .iso image for openSUSE 11.2:
> openSUSE-11.2-DVD-x86_64.iso: 20517 extents found
> turned into:
> openSUSE-11.2-DVD-x86_64.iso: 23 extents found
That ISO file is heavily discontiguous most likely because it
was written incrememtally in many tiny pieces (typically a
download) and the algorithms in the JFS allocator that try to
pick contiguous allocation areas don't handle that well (they
handle fairly well continuous write of largish bits).
> However, how can I do better than that?
On a freshly formatted filesystem that is easy.
> Is there a way to get "1 extents"?
That is pointless. What matters is what percentage of IO is
spent waiting for the head to move. For a 100MB/s and 5ms
repositioning each repositioning displaces 5MB. To keep head
movement delay less than 10% of transfer time one only needs
50MB contiguous regions, and so on.
> I have other .iso images of similar size with 1 extent.
You copied them on a less busy filesystem.
> I was going to explore using posix_fallocate, but I get
> ENOTSUPP...
Regrettably very few Linux filesystems support that. But on a
fresh filesystem it is not needed.
------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Jfs-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jfs-discussion
