Implementing asynchronous file system with FUSE on Linux
Asked Answered
D

1

7

I tried to ask on FUSE's mailing list but I haven't received any response so far... I have a couple of questions. I'm going to implement a low-level FUSE file system and watch over fuse_chan's descriptor with epoll.

  1. I have to fake inodes for all objects in my file system right? Are there any rules about choosing inodes for objects in VFS (e.g. do I have to use only positive values or can I use values in some range)?

  2. Can I make fuse_chan's descriptor nonblocking? If yes, please tell me whether I can assume that fuse_chan_recv()/fuse_chan_send() will receive/send a whole request structure, or do I have to override them with functions handling partial send and receive?

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

Desperate answered 25/1, 2011 at 13:52 Comment(1)
Wicked. 666... Don't use FUSE, implement a proper filesystem driver in Linux kernel. FUSE sucks.Adventurous
R
2

(1) Inodes are defined as unsigned integers, so in theory, you could use any values. However, since there could be programs which are not careful, I'd play it safe and only use non-zero, positive integers up to INT_MAX.

(2) Fuse uses a special kernel device. While fuse_chan_recv() do not support partial reads, this may not be required, as kernel should not return partial packets anyway.

(3) Filenames in Linux are max 4096 chars. This puts a limit on a buffer size:

$ grep PATH_MAX /usr/include/linux/limits.h
#define PATH_MAX        4096    /* # chars in a path name including nul */
Ragen answered 12/7, 2011 at 22:33 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.