The FUSE protocol has a plethora of optional features. Many have not yet been implemented in FreeBSD, but most of them could be. Which new features would you like to see? Check all that apply. If there's something you want that's not listed, add it in the comments.
Event Timeline
Update: The protocol's specification for poll is completely broken in version 7.11. It gets fixed in 7.21. But even so, I cannot find a single fuse file system that uses it. If you know of one, please let me know. And FYI, even without FUSE_POLL support poll(2), select(2), and kevent(2) will still work fine for fifos and sockets stored on a fuse file system. aio(4) also works fine. FUSE_POLL is only needed to do poll(2) or select(2) on regular files.
Update: I have finished readahead and cache invalidation. I'm close to finishing writeback cache improvements. I don't know if I'll have time for the others. posix_fallocate at least should be very easy, so I may do that one anyway.
Alan @asomers,
Would it be possible to re-open the poll, please? We had to discuss these features internally and due to business trips and holiday season it wasn't possible to do it earlier.
Thank you in advance,
Piotr
@piotr.konopelko_moosefs.com does MooseFS use FUSE_POLL for regular files? poll(2) already works just fine for unix-domain sockets stored on fuse file systems. The new feature is just to make it work with regular files. Currently, poll(2) will immediately return ready for regular files stored on fusefs.
Thank you @asomers,
Voted. Let me add some comments from our (distributed file system engineers) perspective:
Features we voted for:
- Cache invalidation – of course very desired feature. In MooseFS we currently use "direct" mode on FreeBSD, but eventually it would be perfect to use standard I/O with cache;
- Writeback cache improvements – important from our perspective. Everything what can get us closer to the performance on Linux libfuse implementation is necessary;
- flock support – definitely yes!
- Readahead – similarly as Writeback cache – important from the perspective of speed / efficiency. Reads and writes done in 4k block don't have much sense these days;
- poll support – currently not supported by MooseFS but why not in the future. Would be nice, but this is not "number 1" feature :)
Other features:
- Birthtime – MooseFS (as many other file systems) doesn't support it;
- posix_fallocate – not necessary, anyway it is a Linuxism. Lots of operating systems does not have / implement this feature. And we do not know how we could support it from MooseFS perspective (always return "ok"?).
Many thanks,
Piotr
In general I prefer we support a lower number of the protocol but that we support it well.
We should support SEEK_DATA|HOLE: it is supported on FreeBSD's main file systems, and it is not too difficult to reach that version protocol-wise.
About birthtime, while the apple/darwin implementation of fuse had it as an extension, but this is not something that is usually supported at the API level: the systems that support it (UFS and ext2) do their thing from within the C library. I don't think we should spend time on it.
About ACLs, fsu@ did them for ext2fs, and he proposed a patch for the linuxulator but there is not much interest for them AFAICT.
Somewhat off-topic, our version of glusterfs is antique. I wonder if it was something missing in fusefs that has stopped the updates from arriving.
Its an ext4 feature, linux calls it crtime (creation time), just to be different ;).
you can find it in our ext2_dinode.h
struct ext2fs_dinode {
...
uint32_t e2di_crtime; /* 144: Creation (birth)time */
uint32_t e2di_crtime_extra; /* 148: Extra creation (birth)time */
...}