Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

How POSIX-compatible is it exactly? There's a lot of niche features that tend to break on not fully compliant network filesystems. Do unlinked files remain accessible (the dreaded ESTALE on some NFS implementations)? mmap? atomic rename? atomic append? range locks? what's the consistency model?

Some of those things don't appear to be covered by pjdfstest.



Good question, we should put these in readme:

1. Unlinked file remain accessible, when it's unlink from same machine. 2. mmap is supported. 3. atomic rename is supported. 4. Is there atomic append in POSIX? 5. range lock is supported. 6. the consistency mode is open-after-close, which means once a file is closed, you can open and read the latest data.



That and further POSIX requires that a read which can be proven to occur after a write returns the new data (I'd think that would be quite difficult to implement efficiently, if multiple clients are allowed). I couldn't find that being mentioned in either the documentation of juicefs nor the pjdfs test.


Most of network file system provide open-after-close consistency, same to JuiceFS, it's mentioned here [1]:

https://github.com/juicedata/juicefs#posix-compatibility




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: