This is the mail archive of the
mailing list for the Cygwin project.
Re: FUSE for Cygwin
- From: Herbert Stocker <hersto at gmx dot de>
- To: cygwin at cygwin dot com
- Date: Sun, 19 Jun 2016 22:32:00 +0200
- Subject: Re: FUSE for Cygwin
- Authentication-results: sourceware.org; auth=none
- References: <D389ABB9 dot 931F%billziss at navimatics dot com> <57667FEF dot 5070801 at gmx dot de> <D38C1E3D dot 9385%billziss at navimatics dot com>
i agree with you that there are only two context switches involved
and that Cygwin processes are not 2nd class performance.
But i was *not* talking about context switches.
i was talking about *translating of semantics* mostly in my mail.
Because i was trying to avoid translation from Posix to Win32
*and back*, just to go from Cygwin process to Cygwin process.
And the reason i want to avoid the translations is not performance.
It is because mode (4) does not have those issues that WinFsp must
take care of in (3). See my points B) to G).
Please also see the end of this mail, i overlooked something you did
not. So i'm now more biased towards (3).
Now some specific answers:
>> E) Same for uid/gid to SID mapping.
>> No need to implement or follow Cygwin.
>> And how about the case where a uid/gid has no correspoinding SID?
>> Can this happen?
> Yes, it can, but this is an issue that Cygwin faces itself.
It will not face it if communication between both Cygwin processes
does not leave Posix semantics. See what i try to avoid?
>> F) Pipes:
> Good catch this one!
> Of course I can try to fix this in the WinFsp/FUSE layer
> implementation, but the fix would probably be a gross and
> Cygwin-specific hack.
Mode (4) would avoid such things *by design*.
Not because we happen to catch all of them.
To fix this with mode (3) you'd have to recognize these .lnk
files and forward them to the file system as pipes, and you'd
have to generate .lnk files on the fly when the file system
says there is a pipe file (e.g. on readdir).
Yes, I agree. Not pretty!
But please do that if you stay with mode (3).
G) Case sensitivity.
WinFsp (and Windows) allows for both case-sensitive and case-insensitive
FUSE file systems are marked as case-sensitive by default.
If WinFsp marks FUSE file systems as case-sensitive then there is no
issue with case sensitiity.
However we should have a look into OSXFUSE, it also has to deal with
case sensitivity. Let's see how they solved it. There's also MacFUSE
and Fuse4X according to Wikipedia.
Just to clarify: I believe that Cygwin processes are already on the same
class as Win32 processes when it comes to a WinFsp exposed file system.
There are no extra context switches
Context switch wise they are the same class. But i was not concerned
about context switches.
Even if you created an intermediate Cygwin process (that
acted as a WinFsp file system) to let Win32 processes access these FUSE
That was defintively my aim. And i think we should use WinFsp for that.
you would now make those Win32 processes 2nd class citizens,
as they would have to go through that intermediate process (which means 4
context switches per file system request for them).
You are right. I did not think about this extra process. Performance
wise Win32 processes would be 2nd class. i was just thinking about
feature wise, where they don't lose.
Now this argument of yours makes me more biased towards mode (3). Let's
pay with some design unprettiness (remember pipes) and have the better
performance for both worlds.
And besides, the translations are necessary anyway for mode (2).
Except for the pipes and hardlinks, they need not be supported in
as before, i am looking forward to use WinFsp and have FUSE available
for my Cygwin scripts and stuff. And even for windows processes.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple