Re: [EXT] Re: consider dropping defrag of journals on btrfs

[Chris Murphy <lists@xxxxxxxxxxxxxxxxx>]

On Mon, Feb 8, 2021 at 1:24 AM Ulrich Windl
<Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> I didn't follow the thread tightly, but there was a happy mix of IOps,
> fragments (and no bandwidth),
> but I wonder here: Isn't it concept of BtrFS that writes are fragmented if
> there is no contiguous free space?
> The idea was *not* to spend time trying to find a goot spoace to write to, but
> use the next available one.

Basically correct. It will merge random writes such that they become
sequential writes. But it means inserts/appends/overwrites for a file
won't be located with the original extents.


> >> If you want an optimization that's actually useful on Btrfs,
> >> /var/log/journal/ could be a nested subvolume. That would prevent any
>
> Actually I stil ldidn't get the benefit of a BtrFS subvolume, but that 's a
> different topic:
> Don't all wrtites end up in a single storage pool?

Subvolumes/snapshots are file b-trees. It's the granularity of
snapshots, send/receive, and the fsync log tree. And at least user
space tools don't do recursive snapshotting, so they stop at subvolume
boundaries which can be important in some cases if the intent is to
use nodatacow. Snapshots results in nodatacow files being subject to
cow.

--
Chris Murphy
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel