On Wed, Jun 2, 2021 at 5:59 AM Gerald Pfeifer <gp@suse.com> wrote:
On Wed 2021-06-02, Niklas Haas wrote:
Neal Gompa wrote:
this code makes the change not atomic and frankly quite scary. Non-atomic rename is better than unbootable unrecoverable broken system.
Shouldn't you bug the OpenZFS people to implement renameat(2) instead? I did: https://github.com/openzfs/zfs/issues/2256
OpenZFS not supporting this yet isn't a good reason to brick users' systems, IMO.
I'm a little puzzled by this exchange.
Niklas' system got bricked, he debugged the issue, nudged upstream (ZFS in this case) about it *and* submitted a patch to work around the issue in openSUSE until hopefully fixed upstream.
His patch does not appear to affect "supported" file systems in openSUSE; it adds a fall back that tries to avoid bricking.
It looks to me Niklas has gone out of his way to help others and contribute. That, plus if this helps just one other user, isn't this good?
Obviously my opinion doesn't matter since I'm not the maintainer, but I'd be worried about cases where this fallback code could be triggered, since the operation is not atomic, and that could make failures quite weird. Perhaps it doesn't matter in this case, but I'm always *extremely* wary of pretending that atomic ops aren't needed when code is written to assume atomic ops. OpenZFS might be fine because of other aspects of the filesystem, but what about network filesystems? If it's booted over NFS or Samba or some other network protocol, I'd be scared unless there was more hardening. -- 真実はいつも一つ！/ Always, there's only one truth!