4 ms·

Does anyone happen to know if ZFS also suffers from renames being non-atomic? Since ZFS is the only candidate for a reasonable file system we have anyway[+], I'

by patrec 7y ago

Does anyone happen to know if ZFS also suffers from renames being non-atomic? Since ZFS is the only candidate for a reasonable file system we have anyway[+], I'd be a lot less sad if it turns out that way out of this dumpster fire is just tell people to use ZFS. [+] The absolutely minimal requirement for a reasonable file system is that it works on multiple popular platforms and performs checksumming and other data integrity measures. And that's before we even get to still highly desirable stuff like snaphotting, encryption, etc.

xxpor 7y ago
I love ZFS but the licence situation means it'll always be a mess to use.
- patrec 7y ago
  Yes, it's sad. Even more so since there is not even a potential competitor in sight.
Filligree 7y ago
ZFS never reorders metadata operations in an observable manner, so it's really well behaved. If only every filesystem was like that... You still need fsync for the data, but you can set sync=disabled on the filesystem, which turns it into a barrier. Alas, you can't do anything more granular than per-filesystem.
- patrec 7y ago
  Does this idiom (which turns out to be broken on rename op failure for most FSs) work reliably with ZFS (on the same filesystem)? def atomically_write(filename, data): with open(filename + '.tmp', 'w') as fh: fh.write(data) os.rename(filename + '.tmp', filename) In addition to ordering guarantees, you also need to guarantee that even in case of failure the rename operation leaves the to-be-renamed file as it is and the to-be-renamed-to file non-existent – is that the case? > If only every filesystem was like that.. I wonder if the solution for databases and other server software that needs to persist data reliably is just pretend they are and insist on end-users sticking to non-broken filesystems (most probably ZFS, assuming the set is currently non-empty). The alternative of wasting endless time and resources on sysiphean quests to placate crap filesystems seems to have been an utter failure so far.
  - Filligree 7y ago
    I'm actually not sure if that code would work, but I don't think it would. You need at least one fsync in there, before the rename.

by patrec 7y ago

xxpor 7y ago

I love ZFS but the licence situation means it'll always be a mess to use.

patrec 7y ago
Yes, it's sad. Even more so since there is not even a potential competitor in sight.

Filligree 7y ago

ZFS never reorders metadata operations in an observable manner, so it's really well behaved. If only every filesystem was like that... You still need fsync for the data, but you can set sync=disabled on the filesystem, which turns it into a barrier. Alas, you can't do anything more granular than per-filesystem.

patrec 7y ago
Does this idiom (which turns out to be broken on rename op failure for most FSs) work reliably with ZFS (on the same filesystem)? def atomically_write(filename, data): with open(filename + '.tmp', 'w') as fh: fh.write(data) os.rename(filename + '.tmp', filename) In addition to ordering guarantees, you also need to guarantee that even in case of failure the rename operation leaves the to-be-renamed file as it is and the to-be-renamed-to file non-existent – is that the case? > If only every filesystem was like that.. I wonder if the solution for databases and other server software that needs to persist data reliably is just pretend they are and insist on end-users sticking to non-broken filesystems (most probably ZFS, assuming the set is currently non-empty). The alternative of wasting endless time and resources on sysiphean quests to placate crap filesystems seems to have been an utter failure so far.
- Filligree 7y ago
  I'm actually not sure if that code would work, but I don't think it would. You need at least one fsync in there, before the rename.