On Mon, Dec 14, 2009 at 3:46 PM, Peter Grandi <[email protected]> wrote:
>
>> 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.

I've had very good success at doing that on a much larger basis.
Obviously there are cases where it won't work well (such as when disk
space is not available), but in my couple of a dozen experiments it
never failed to substantially improve overall fragmentation -
frequently by quite a bit.  Several filesystems I tested with had over
40% fragmentation (as reported by e2fsck) and each one of them ended
up in the single digits.

>> 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).

Yes, I know why it was discontiguous. What I'm asking is what
filesystem operations best suit large JFS allocations. Should I
allocate the entire file by way of truncate? Should I write a \0 every
4K (this is similar to what fallocate_posix does in glibc) for the
size of the file? Normally I use truncate but I've had good success
with both methods. I'm asking specifically for the best way to do this
*for JFS*.

>> Is there a way to get "1 extents"?

> That is pointless. What matters is what percentage of IO is

I should have asked "what is the most optimal way to allocate space
for large files on JFS".


>> I have other .iso images of similar size with 1 extent.
>
> You copied them on a less busy filesystem.

The filesystem was no more or less busy, but that's non the matter.


-- 
Jon

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

Reply via email to