Re: [RFC] Self healing extent map OR opportunistic de-fragmentation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Nov 9, 2010 at 10:58 AM, Andreas Dilger
<adilger.kernel@xxxxxxxxx> wrote:
> On 2010-11-08, at 21:14, Amir Goldstein wrote:
>> I would like to propose a simple idea how to automatically de-fragment a file.
>
> [snip]
>
>> The use case for this, besides healing fragmentation caused by
>> snapshots move-on-rewrite, is an highly fragmented ext2/3 fs, which was mounted as ext4.
>> ext2/3 old files are slowly being deleted while new (still fragmented) extent mapped files are being created.
>> This viscous cycle cannot end before there is enough contiguous free
>> space for writing new files, which may never happen.
>
> This will only happen in case the free space is _very_ low.  Normally, in a situation like this, mballoc will allocate the
> largest contiguous chunks of free space, reducing the fragmentation as new files are written, and allocations to
> highly-fragmented block groups will be avoided until the chunks in those groups have grown larger.
>
>> Online de-fragmentation will not help in this case either.
>> With opportunistic de-fragmentation, if the extent mapped files are
>> being re-written, the health of the file system will constantly improve over time.
>> BTW, Is this use case relevant for upgraded google chunk servers?
>
> While this is true in theory, the problem is that in most cases files are not overwritten in place.
> Commonly, when files are "rewritten" they are truncated and new blocks allocated, or a new file is written and renamed in place of the old file.
> Only in rare cases, like databases, are files rewritten in-place.
>

Oh, I know that. Which is why it is a bit annoying to invest a lot of
effort to solve the fragmentation caused by snapshot move-on-rewrite.
In those rare use cases, the file may end up like a swiss cheese after
a while. However, I realized that the access pattern of those
applications
in not all that random. A rewrite to offset X has a high likelihood to
repeat more than once (update to DB record or write of metadata block
in virtual disk).
I figured I could use the opportunity of the subsequent rewrites to
restore the file blocks to their original location, without paying a
performance trade-off.

The question is, are there other use cases out there that can benefit
from opportunistic de-fragmentation?

Amir.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux