Implementing an Asynchronous File System with FUSE on Linux

I tried to ask on the FUSE mailing list, but still have not received an answer ... I have a couple of questions. I am going to implement a low-level FUSE file system and monitor the fuse_chan handle with epoll.

  • Do I need to fake inodes for all objects in my file system? Are there any rules for choosing inodes for objects in VFS (for example, should I use only positive values ​​or can I use values ​​in a certain range)?

  • Is it possible to write a fuse_chan non-blocking descriptor? If yes, please tell me can I assume that fuse_chan_recv() / fuse_chan_send() will receive / send the entire request for the structure, or do I need to redefine them with the partial send and receive processing functions?

  • What about buffer size ? I see this in fuse_loop() new buffer allocated for each call, so I assume that the buffer size is not fixed. However, maybe there is some maximum possible buffer size? Then I can allocate a larger buffer and reduce memory allocation operations.

+7
source share
1 answer

(1) Inodes are defined as unsigned integers, so theoretically you can use any value. However, since there may be programs that are not careful, I would play them safely and use only nonzero positive integers before INT_MAX.

(2) Fuse uses a special kernel. Although fuse_chan_recv () does not support partial reads, this may not be necessary, since the kernel should not return partial packets in any case.

(3) Linux file names are a maximum of 4096 characters. This limits the size of the buffer:

 $ grep PATH_MAX /usr/include/linux/limits.h #define PATH_MAX 4096 /* # chars in a path name including nul */ 
+2
source

All Articles