[SLL] overcoming NFS group limits

[Derek Simkowiak]

/> You'll see a roughly ~5% slowdown in file transfer speeds [with 
SSHFS].../

    Just a quick addendum... I've been Googling for some hard stats on 
SSHFS numbers and noticed widely varying forum reports with SSHFS.  
Everything from "300% slower than NFS" to "faster than NFS" (which makes 
no sense unless SSH's compression was being used over a slow link).

    My 5% estimate came from old hardware, from years ago.  From reading 
online, it looks like SSHFS doesn't hold up as well with GigE.  The 
cipher you use also makes a big impact.  (I.e., you'd probably want 
Blowfish, which is probably not the default.)

    So, that 5% estimate is +/- 300%.  I'll need to run some tests of 
NFS vs SSHFS on my current servers, when I get some time...

--Derek

P.S.> While Googling I was also reminded of CurlFtpFS, another FUSE 
solution based on FTP (so, no encryption).


On 05/11/2009 03:12 PM, Derek Simkowiak wrote:
> 2) Are there any alternatives to NFS?
>
>
>    NFS It is the only well-established file sharing network protocol 
> that natively supports the concept of Unix UIDs and GIDs.  Samba 
> "SMB", Appletalk, WebDAV, etc. do not directly support the UIDs and 
> GIDs of a Unix filesystem.  (There are various "mapping" solutions, 
> but they're all ugly.)
>
>    NFS is also a nightmare.  I've seen a mis-behaving NFS mount cause 
> system failures (like server freezes) on at least three Big Production 
> Systems.  The root cause is that NFS is implemented directly in the 
> kernel (although, a user space NFS for Linux does exist).  There are 
> various options to make NFS play nice, but when problems happen, they 
> can be very serious -- like, you can't SSH in anymore kind of serious.
>
>    You mentioned large files; if all your servers are in the same data 
> center, you may want to consider moving from a TCP/IP networked 
> filesystem to a shared backend storage, like a fiber SAN using the GFS 
> filesystem.  But that's a major architecture change, and probably not 
> what you're looking for.  (It would be a lot faster, though.)
>
>    There is one alternative to NFS that supports the native Unix UIDs 
> and GIDs: SSHFS.  SSHFS is a FUSE filesystem.  It allows any user to 
> remotely mount a filesystem using SSH.
>    SSHFS runs in userspace, not in the kernel, so a dirty SSHFS mount 
> won't kill your server.  Like NFS, SSHFS is smart about local 
> caching.  It's also smart about intermittent network connections.  My 
> favorite feature is that SSHFS access can be controlled via SSH keys, 
> which is light years beyond what NFS can offer in terms of security 
> and management policies (*cough* "root_squash" *cough*).
>
>    The one (and only?) drawback to SSHFS is that OpenSSH forces you to 
> use encryption.  You'll see a roughly ~5% slowdown in file transfer 
> speeds, due to the encryption and due to the fact it's user space 
> instead of kernel space.  Personally, I'm willing to live with that 5% 
> just to get key-based authentication.  The warm'n'fuzzy feeling that 
> comes from knowing all my network traffic is encrypted is just icing 
> on the cake...
>
>    My advice is to try SSHFS and see what happens.
>
>
> --Derek
> http://cool-st.com/
>
>
> On 05/11/2009 02:14 PM, Ted Stern wrote:
>> This is more of a general Unix question, but I'm looking for a
>> solution on a Linux server.
>>
>> If a user accesses an NFS-mounted disk, NFS supports only the first 16
>> groups of which that user is a member.
>>
>> This might seem ample for most small systems, but I'm at a large
>> company with lots of projects, and due to accounting rules a plethora
>> of groups were created over the years.
>>
>> We've done a major group cleanup (which should have been done anyway)
>> but there are still some users who, because of their involvement with 
>> many
>> projects, have to be members of lots of groups.
>>
>> So, two questions:
>>
>> 1) Is there any hope that NFS will support more than 16 groups in the
>> near future?
>>
>>
>> 2) Are there any alternatives to NFS?
>>
>> 3) Are there any network mountable filesystems that have support for
>> access control lists?  Note that the protocol has to be at least as
>> fast as NFS because we're supporting multi-GB file access.
>>
>> Thanks,
>>
>> Ted
>>