On Tue, Jan 31, 2012 at 6:14 AM, Ken Hornstein
<email@hidden> wrote:
>Is there any way to distinguish if operations (read/write/..) are run
>against different descriptors? Currently fuse4x does an ugly hack - it
>stores 3 descriptors per vnode - for read-only/write-only/rdrw descriptors.
>It means if the same file is open 2 times with there same mode (e.g.
>RDONLY) then fuse4x uses only one file descriptor. For fuse userspace it
>looks like the file was opened only once and all read operations are done
>for the same file descriptor.
I feel your pain, because I ported a Linux filesystem to MacOS X
and I had to deal with a ton of issues like this. Shantonu has
already given you the authoritative answer (no), but it occurs to
me that you have some alternate options.
You get notified of an open with a VOP_OPEN, and you get the mode of
the open at that time. So you could use that to create new file
descriptors ... although you will probably have a hard time in practice
matching up a request with a descriptor. You could at least distinguish
between different modes of open.
But something occurs to me - let's say three different processes
open the same file with the same mode, so the fuse backend shares
a descriptor among the different open requests. So what? I mean,
how exactly is that a problem?
Fuse at Linux passes the id unique to a file structure to userspace. And it is difficult to guess how a fuse filesystem is going to use this id. For example SSHFS keeps a readahead buffer for every file descriptor. If there are 2 descriptors read the same file then SSHFS will be confused - readahead buffer will be read but then dropped as other descriptor reads remote file at different offset (if I understand sshfs sources correctly).
Anyway it seems there is no easy way to get the file structure for VNOP and we have to stick with the solution from macfuse. It has been working fine for macfuse for several years....
> Or why another fuse clone?
Historically fuse4x appeared several month before osxfuse. I was migrating a tool from Linux to OSX and discovered that MacFuse breaks compatibility with linux fuse in several important areas (e.g. macfuse does not work in multi-thread applications). I asked if it should be fixed in macfuse - it requires quite a lot of changes in libfuse and kext and changes some macfuse-specific API. But I've got answer that "macfuse is not fuse" and they do not want to change it
http://osdir.com/ml/macfuse/2011-05/msg00032.html So I followed way "if you want to be done - do it yourself" and started the macfuse fork. The goals of fuse4x are:
- Keep it compatible as much as possible. Fuse4x should be a reference implementation of fuse on macosx.
- Keep sources clean simple. Remove API that looks weird or does not follow spirit of Fuse.
- Make fuse4x as fast as possible.
osxfuse appeared later with idea to be fully compatible with macfuse (including binary compatibility of the distribution), but this also means they have all the problems that macfuse has.
You get a file offset and size with
every request, so it's not an issue of tracking the offset in the
descriptor. Seems to me this isn't a problem in practice ... unless
I'm missing something (which is always possible).
--Ken
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (
email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden