Re: Feature requests: online backup - defrag - change RAID level

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

 



On Fri, Sep 13, 2019 at 5:04 AM Austin S. Hemmelgarn
<ahferroin7@xxxxxxxxx> wrote:
>
> Do you have a source for this claim of a 128MB max extent size?  Because
> everything I've seen indicates the max extent size is a full data chunk
> (so 1GB for the common case, potentially up to about 5GB for really big
> filesystems)

Yeah a block group can be a kind of "super extent". I think the
EXTENT_DATA maxes out at 128M but they are often contiguous, for
example

    item 308 key (5741459 EXTENT_DATA 0) itemoff 39032 itemsize 53
        generation 241638 type 1 (regular)
        extent data disk byte 193851400192 nr 134217728
        extent data offset 0 nr 134217728 ram 134217728
        extent compression 0 (none)
    item 309 key (5741459 EXTENT_DATA 134217728) itemoff 38979 itemsize 53
        generation 241638 type 1 (regular)
        extent data disk byte 193985617920 nr 134217728
        extent data offset 0 nr 134217728 ram 134217728
        extent compression 0 (none)
    item 310 key (5741459 EXTENT_DATA 268435456) itemoff 38926 itemsize 53
        generation 241638 type 1 (regular)
        extent data disk byte 194119835648 nr 134217728
        extent data offset 0 nr 134217728 ram 134217728
        extent compression 0 (none)

Where FIEMAP has a different view (via filefrag -v)

 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..  131071:   47327002..  47458073: 131072:
   1:   131072..  294911:   47518701..  47682540: 163840:   47458074:
   2:   294912..  360447:   50279681..  50345216:  65536:   47682541:
   3:   360448..  499871:   50377984..  50517407: 139424:   50345217: last,eof
Fedora-Workstation-Live-x86_64-31_Beta-1.1.iso: 4 extents found

Those extents are all bigger than 128M. But they're each made up of
contiguous EXTENT_DATA items.

Also, the EXTENT_DATA size goes to a 128K max for any compressed
files, so you get an explosive number of EXTENT_DATA items on
compressed file systems, and thus metadata to rewrite.

I wonder if instead of a rewrite of defragmenting, if there could be
improvements to the allocator to write bigger extents. I guess the
problem really comes from file appends? Smarter often means slower but
perhaps it could be a variation on autodefrag?


-- 
Chris Murphy



[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux