Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame^] | 1 | Here are some good questions and answers in no particular order. |
| 2 | |
| 3 | --------------------------------------------------------------------------- |
| 4 | Subject: FUSE vs. LUFS |
| 5 | |
| 6 | |
| 7 | > Can you explain me what are the differences between this two modules |
| 8 | > and why did you start a new project? |
| 9 | |
| 10 | Well looking at the release dates on SF, the first release of FUSE is |
| 11 | almost a year older than that of LUFS. But we probably weren't awere |
| 12 | of each others project for quite some time. |
| 13 | |
| 14 | The main difference between them is that in LUFS the filesystem is a |
| 15 | shared object (.so) which is loaded by lufsmount, and in FUSE the |
| 16 | filesystem is a separate executable, which uses the fuse library. The |
| 17 | actual API is very similar, and I've written a translator, that can |
| 18 | load LUFS modules and run them using the FUSE kernel module (see the |
| 19 | lufis package on the FUSE page). |
| 20 | |
| 21 | Another difference is that LUFS does some caching of directories and |
| 22 | file attributes. FUSE does not do this, so it provides a 'thinner' |
| 23 | interface. |
| 24 | |
| 25 | --------------------------------------------------------------------------- |
| 26 | Subject: close() not in struct fuse_operations |
| 27 | |
| 28 | |
| 29 | > Is there a reason for 'close' not being one of the |
| 30 | > fuse_operations? I'd need to know when files are |
| 31 | > closed... |
| 32 | |
| 33 | It's not easy. Consider mmap(): if you have a memory file, even after |
| 34 | closing it, you can read or write the file through memory. |
| 35 | |
| 36 | Despite this there are close()-like operations: flush and release. |
| 37 | Flush gets called on each close() and release gets called when there |
| 38 | are no more uses of a file, including memory mappings. |
| 39 | |
| 40 | --------------------------------------------------------------------------- |
| 41 | Subject: overlapping open/release states |
| 42 | |
| 43 | |
| 44 | > I'm using a fairly current CVS version of Fuse, and have noticed |
| 45 | > overlapping open / release calls for a file. In other words a file |
| 46 | > is opened multiple times and receives multiple release calls. Is |
| 47 | > this expected? |
| 48 | |
| 49 | It has always been like this. The open / release calls correspond to |
| 50 | actual file opens / releases. The release is called when there are no |
| 51 | more refernces to the file, i.e. on the last close() or munmap(). |
| 52 | |
| 53 | > This isn't what I expected. Do I need to keep track of how many |
| 54 | > open() calls were made to a file and expect that many release() calls? |
| 55 | |
| 56 | Yes. You can also keep track of the number of files opened for |
| 57 | writing for example, and use that information for finally flushing |
| 58 | dirty data of a file. |
| 59 | |
| 60 | > So it appears that there may even be additional file operations after |
| 61 | > one or more of the release calls.. |
| 62 | |
| 63 | That is expected also. It would be a bug if there were reads/writes |
| 64 | after the last release, or if the number of releases didn't match the |
| 65 | number of opens. |
| 66 | |
| 67 | > I've solved this in my code by counting the number of open / release |
| 68 | > calls and only dropping information when the last expected release |
| 69 | > is received. But I thought I'd point this out in case, as it was |
| 70 | > unexpected behavior.. |
| 71 | |
| 72 | --------------------------------------------------------------------------- |
| 73 | Subject: return value from release() |
| 74 | |
| 75 | |
| 76 | > Hmm. So it doesn't matter what I return from my release function? I |
| 77 | > understand there is not an exact 1:1 relationship between close() and |
| 78 | > release, but I had hoped that a error return from release would be |
| 79 | > carried up as an error return from close(). |
| 80 | |
| 81 | In release() the error value is ignored, and not every close will |
| 82 | cause a release. Consider this: |
| 83 | |
| 84 | - process opens a file |
| 85 | - process forks |
| 86 | - parent closes the file |
| 87 | - child closes the file |
| 88 | |
| 89 | The file will only be released on the second close, i.e. when all |
| 90 | references to the file are closed. Also memory mapping a file creates |
| 91 | a reference to the file, that is released when the memory is unmapped. |
| 92 | |
| 93 | There is a flush() operation that is called on every close(), through |
| 94 | which the filesystem can return an error. |
| 95 | |
| 96 | Note: there can be read/write operations even after the last flush() |
| 97 | but before a release(). |
| 98 | |
| 99 | --------------------------------------------------------------------------- |
| 100 | Subject: FUSE lacks ioctl support |
| 101 | |
| 102 | |
| 103 | > I'll try to add ioctl support to FUSE, but I am quite new to it, so I |
| 104 | > would apreciate any suggestions. |
| 105 | |
| 106 | It's not clear to me how would you use ioctls since they are |
| 107 | meaningless on normal files, and on device files the filesystem |
| 108 | implementation usually does not care about the ioctl operations. And |
| 109 | even if you manage to hack fuse to intercept device ioctls, you |
| 110 | wouldn't be able to do anything with them, because they contain |
| 111 | arbitrarily structured data (not length/value as in the case of read |
| 112 | or write). |
| 113 | |
| 114 | [...] |
| 115 | |
| 116 | Using getxattr() and setxattr() is much cleaner than ioctl(), and is |
| 117 | actually supported in fuse-2.0. |
| 118 | |
| 119 | --------------------------------------------------------------------------- |
| 120 | Subject: Short reads |
| 121 | |
| 122 | |
| 123 | > Now for the problem case: I cat the 256k file, the kernel issues a |
| 124 | > read with length 65536 and offset 0. My program returns only 10 |
| 125 | > bytes. What I expected to see was the kernel to then issue a read for |
| 126 | > length 65536 and offset 10. Instead what I saw in the result was the |
| 127 | > 10 bytes I returned, followed by 65526 zero bytes. |
| 128 | > |
| 129 | > Is this the intended behavior? |
| 130 | |
| 131 | Yes. You can easily program around it with a for-loop in your read |
| 132 | function. |
| 133 | |
| 134 | > Does this simplify things significantly? If it isn't much of a |
| 135 | > difference, I'd like to suggest doing it the other way: many people |
| 136 | > (like me) implement their fuse read function in terms of read(), and |
| 137 | > read() can return early. |
| 138 | |
| 139 | No. Read from a pipe/socket can be short, but read from a file can't. |
| 140 | |
| 141 | --------------------------------------------------------------------------- |
| 142 | Subject: protocol error |
| 143 | |
| 144 | > I'm having trouble with file writing. I can |
| 145 | > 'echo something > file' to a file, but |
| 146 | > 'cp file something' or 'cat something > file' |
| 147 | > gives a protocol error. |
| 148 | |
| 149 | Two possible reasons for this are: |
| 150 | |
| 151 | 1) A mismatch between the library version and the kernel module |
| 152 | version. |
| 153 | |
| 154 | 2) The write() operation returns less than the 'size' parameter. |
| 155 | Short writes are generally not allowed (as in case of read()). The |
| 156 | exception is if the 'direct_io' mount option is used. |
| 157 | |
| 158 | --------------------------------------------------------------------------- |
| 159 | Subject: FUSE naming |
| 160 | |
| 161 | |
| 162 | > There are a million other projects with the same name. Why did you |
| 163 | > call it 'FUSE'? |
| 164 | |
| 165 | Because I'm an imbecile. The lesson is that a common term is not a |
| 166 | good project name. A somewhat strange story comes to my mind: I was |
| 167 | contacted by Philip Kendall shortly after releasing FUSE, blaming me |
| 168 | for choosing the same name as his ZX Spectrum emulator (Fuse). We |
| 169 | have known each other from earlier times, since I have also written a |
| 170 | ZX Spectrum emulator (Spectemu). |
| 171 | |
| 172 | --------------------------------------------------------------------------- |
| 173 | Subject: Uid/gid/pid |
| 174 | |
| 175 | |
| 176 | > Is there any easy way to know the uid of a reader? For example, let's |
| 177 | > say I wanted to create a file that contained 'foo' for uid 1, but |
| 178 | > 'bar' for uid 2. |
| 179 | |
| 180 | Yes: |
| 181 | |
| 182 | fuse_get_context()->uid |
| 183 | |
| 184 | |
| 185 | --------------------------------------------------------------------------- |
| 186 | Subject: 'find' command |
| 187 | |
| 188 | |
| 189 | > I'm having trouble getting the find command to search through fuse |
| 190 | > directories. What settings do I need in 'getattr'? |
| 191 | |
| 192 | use the -noleaf option to find |
| 193 | (find uses the following parameters to determine whether it should recurse |
| 194 | into a subdirectory) |
| 195 | |
| 196 | nr_links must be >= 3 |
| 197 | size must be > 0 |
| 198 | and must be a directory |
| 199 | |
| 200 | so just return those in the getattr for your directories and you wont have |
| 201 | to use -noleaf. |
| 202 | |
| 203 | --------------------------------------------------------------------------- |
| 204 | Subject: File system interactivity |
| 205 | |
| 206 | > I need to add interactivity to my user space file system. |
| 207 | > For example, while executing create(), I need to ask a |
| 208 | > question to the terminal that issued the request. |
| 209 | > |
| 210 | > Is there a way I can achieve this goal? |
| 211 | |
| 212 | It would not be possible generally speaking, since it might not be an |
| 213 | interactive program but rather a daemon, or a GUI program creating the |
| 214 | file. However you should be able to get the PID for the caller, and |
| 215 | by looking in /proc you should be able to find the process tty or |
| 216 | something similar. Perhaps it would be better to redesign your program |
| 217 | not to have such interactivity anyway, try to use e.g. extended |
| 218 | attributes of files to set per-file options, or a configuration file |
| 219 | for your filesystem. |
| 220 | |