Re: fstab autodegrag with 5.10 & 5.15 kernels, Debian?

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

On 2022/1/28 20:14, piorunz wrote:
> Hi all,
>
> Chris, Qu, Kai, thanks for all your replies. :)
>
> As I mentioned, I never considered defragmenting before, so I am not
> experienced in this matter, but now I decided to tackle this problem a
> bit more seriously.
> So yes, I run /home RAID10 on 4 HDDs and I don't want to change it at
> this time. It's running quite fine. I'd love to run RAID 5 or 6 but I
> know this functionality is not ready.
> HDDs are 2TB each in my server, and 500GB each in desktop.
>
> So, I see that solution I found while searching internet (defrag with
> -t4G) is not suitable for compressed Btrfs.
> Also, autodefrag will not work in my case. I use 5.10 and 5.15 kernels.
>
> So, I should manually run:
> sudo btrfs filesystem defrag -v -t128K -r /home
> That will be more suitable, right?

Yep, more suitable for your kernels.

BTW, there is already patch submitted to address some problems with
compressed extents.
Like not to defrag compressed extents which are already at its max size.

For now, your -t128k would emulate that.

>
> I know performance can be improved for databases or VMs I run (6x
> Windows running 24/7), but I don't want to complicate systems more than
> they already are, so I will skip manual attr changes at this point, let
> me try one thing at a time. :)
>
> If manual defragging with -t128K is correct, I can run that regularly,
> please let me know if that would be your consensus guys. Thank you.

With -t 128k you may hit the 120s timeout problem less frequently.

Although sometimes you may want to further reduce the value to something
like 64K, to reduce the workload.

I may craft a fix to add cond_resche() inside btrfs_defrag_file() so
that can be backported to v5.15, to let the problem to be gone for good.

Thanks,
Qu

>
> On 28/01/2022 11:55, Kai Krakow wrote:
>> Hi!
>>
>> Am Fr., 28. Jan. 2022 um 08:51 Uhr schrieb piorunz <piorunz@gmx.com>:
>>
>>> Is it safe & recommended to run autodefrag mount option in fstab?
>>
>> I've tried autodefrag a few times, and usually it caused btrfs to
>> explode under some loads (usually databases and VMs), ending in
>> invalid tree states, and after reboot the FS was unmountable. This may
>> have changed meanwhile (last time I tried was in the 5.10 series).
>> YMMV. Run and test your backups.
>>
>>
>>> I am considering two machines here, normal desktop which has Btrfs as
>>> /home, and server with VM and other databases also btrfs /home. Both
>>> Btrfs RAID10 types. Both are heavily fragmented. I never defragmented
>>> them, in fact. I run Debian 11 on server (kernel 5.10) and Debian
>>> Testing (kernel 5.15) on desktop.
>>
>> Database and VM workloads are not well suited for btrfs-cow. I'd
>> consider using `chattr +C` on the directories storing such data, then
>> backup the contents, purge the directory empty, and restore the
>> contents, thus properly recreating the files in nocow mode. This
>> allows the databases and VMs to write data in-place. You're losing
>> transactional guarantees and checksums but at least for databases,
>> this is probably better left to the database itself anyways. For VMs
>> it depends, usually the embedded VM filesystem running in the images
>> should detect errors properly. That said, qemu qcow2 works very well
>> for me even with cow but I disabled compression (`chattr +m`) for the
>> images directory ("+m" is supported by recent chattr versions).
>>
>>
>>> Running manual defrag on server machine, like:
>>> sudo btrfs filesystem defrag -v -t4G -r /home
>>> takes ages and can cause 120 second timeout kernel error in dmesg due to
>>> service timeouts. I prefer to autodefrag gradually, overtime, mount
>>> option seems to be good for that.
>>
>> This is probably the worst scenario you can create: forcing
>> compression forces extents to be no bigger than 128k, which in turn
>> increases IO overhead, and encourages fragmentation a lot. Since you
>> are forcing compression, setting a target size of 4G probably does
>> nothing, your extents will end up with 128k size.
>>
>> I also found that depending on your workload, RAID10 may not be
>> beneficial at all because IO will always engage all spindles. In a
>> multi-process environment, a non-striping mode may be better (e.g.
>> RAID1). The high fragmentation would emphasize this bottleneck a lot.
>>
>>
>>> My current fstab mounting:
>>>
>>> noatime,space_cache=v2,compress-force=zstd:3 0 2
>>>
>>> Will autodefrag break COW files? Like I copy paste a file and I save
>>> space, but defrag with destroy this space saving?
>>
>> Yes, it will. You could run the bees daemon instead to recombine
>> duplicate extents. It usually gives better space savings than forcing
>> compression. Using forced compression is probably only useful for
>> archive storage, or when every single byte counts.
>>
>>
>>> Also, will autodefrag compress files automatically, as mount option
>>> enforces (compress-force=zstd:3)?
>>
>> It should, but I never tried. Compression is usually only skipped for
>> very small extents (when it wouldn't save a block), or for inline
>> extents. If you run without forced compression, a heuristic is used
>> for whether compressing an extent.
>>
>>
>> Regards,
>> Kai
>
>
> --
> With kindest regards, Piotr.
>
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
> ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
> ⠈⠳⣄⠀⠀⠀⠀