Re: consider dropping defrag of journals on btrfs

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Sa, 06.02.21 19:47, Chris Murphy (lists@xxxxxxxxxxxxxxxxx) wrote:
65;6201;1c
> On Fri, Feb 5, 2021 at 8:23 AM Phillip Susi <phill@xxxxxxxxxxxx> wrote:
>
> > Chris Murphy writes:
> >
> > > But it gets worse. The way systemd-journald is submitting the journals
> > > for defragmentation is making them more fragmented than just leaving
> > > them alone.
> >
> > Wait, doesn't it just create a new file, fallocate the whole thing, copy
> > the contents, and delete the original?
>
> Same inode, so no. As to the logic, I don't know. I'll ask upstream to
> document it.
>
> ?How can that possibly make
> > fragmentation *worse*?
>
> I'm only seeing this pattern with journald journals, and
> BTRFS_IOC_DEFRAG. But I'm also seeing it with all archived journals.
>
> Meanwhile, active journals exhibit no different pattern from ext4 and
> xfs, no worse fragmentation.

That's not surprising, these file systems don't have a defrag
ioctl with similar generic semantics.

> Is there a VFS API for handling these isues? Should there be? I really
> don't think any application, including journald, should be having to
> micromanage these kinds of things on a case by case basis. General
> problems like this need general solutions.

We don't micromanage. We call a simple, extremely generic ioctl, that
takes exactly zero parameters, asking btrfs to do its best.

> > It sounds like you are arguing that it is better to do the wrong thing
> > on all SSDs rather than do the right thing on ones that aren't broken.
>
> No I'm suggesting there isn't currently a way to isolate
> defragmentation to just HDDs.

We could add one. For example, the $SYSTEMD_JOURNAL_DEFRAG env var I
proposed in that other mail could have a special value besides yes/no
of "ssd" or so, where we'd use btrfs own understanding if it's backed
by ssd or rotating media, as controlled with the ssd/nossd mount
option. (though ideally we'd have a better way to query it that to
parse out the mount options string)

Lennart

--
Lennart Poettering, Berlin
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel