On Tue, Feb 07, 2023 at 01:31:44PM +0100, Hans Holmberg wrote: > On Mon, Feb 6, 2023 at 3:24 PM Johannes Thumshirn > <Johannes.Thumshirn@xxxxxxx> wrote: > > > > On 06.02.23 14:41, Hans Holmberg wrote: > > > Out of the upstream file systems, btrfs and f2fs supports > > > the zoned block device model. F2fs supports active data placement > > > by separating cold from hot data which helps in reducing gc, > > > but there is room for improvement. > > > > FYI, there's a patchset [1] from Boris for btrfs which uses different > > size classes to further parallelize placement. As of now it leaves out > > ZNS drives, as this can clash with the MOZ/MAZ limits but once active > > zone tracking is fully bug free^TM we should look into using these > > allocator hints for ZNS as well. > > > > That looks like a great start! > > Via that patch series I also found Josef's fsperf repo [1], which is > exactly what I have > been looking for: a set of common tests for file system performance. I hope that > it can be extended with longer-running tests doing several disk overwrites with > application-like workloads. It should be relatively straightforward to add more tests to fsperf and we are happy to take new workloads! Also, feel free to shoot me any questions you run into while working on it and I'm happy to help. > > > The hot/cold data can be a 2nd placement hint, of cause, not just the > > different size classes of an extent. > > Yes. I'll dig into the patches and see if I can figure out how that > could be done. FWIW, I was working on reducing fragmentation/streamlining reclaim for non zoned btrfs. I have another patch set that I am still working on which attempts to use a working set concept to make placement lifetime/lifecycle a bigger part of the btrfs allocator. That patch set tries to make btrfs write faster in parallel, which may be against what you are going for, that I'm not sure of. Also, I didn't take advantage of the lifetime hints because I wanted it to help for the general case, but that could be an interesting direction too! If you're curious about that work, the current state of the patches is in this branch: https://github.com/kdave/btrfs-devel/compare/misc-next...boryas:linux:bg-ws (Johannes, those are the patches I worked on after you noticed the allocator being slow with many disks.) Boris > > Cheers, > Hans > > [1] https://github.com/josefbacik/fsperf
