On 15.03.2022 13:14, Matias Bjørling wrote:
>
>All that said - if there are people willing to do the work and it doesn't have a
negative impact on performance, code quality, maintenance complexity, etc.
then there isn't anything saying support can't be added - but it does seem like
it’s a lot of work, for little overall benefits to applications and the host users.
Exactly.
Patches in the block layer are trivial. This is running in production loads without
issues. I have tried to highlight the benefits in previous benefits and I believe
you understand them.
Support for ZoneFS seems easy too. We have an early POC for btrfs and it
seems it can be done. We sign up for these 2.
As for F2FS and dm-zoned, I do not think these are targets at the moment. If
this is the path we follow, these will bail out at mkfs time.
If we can agree on the above, I believe we can start with the code that enables
the existing customers and build support for butrfs and ZoneFS in the next few
months.
What do you think?
I would suggest to do it in a single shot, i.e., a single patchset, which enables all the internal users in the kernel (including f2fs and others). That way end-users do not have to worry about the difference of PO2/NPO2 zones and it'll help reduce the burden on long-term maintenance.
Thanks for the suggestion Matias. Happy to see that you are open to
support this. I understand why a patchseries fixing all is attracgive,
but we do not see a usage for ZNS in F2FS, as it is a mobile
file-system. As other interfaces arrive, this work will become natural.
ZoneFS and butrfs are good targets for ZNS and these we can do. I would
still do the work in phases to make sure we have enough early feedback
from the community.
Since this thread has been very active, I will wait some time for
Christoph and others to catch up before we start sending code.
