Poettering: Revisiting how we put together Linux systems

Posted Sep 4, 2014 15:09 UTC (Thu) by bfields (subscriber, #19510)
In reply to: Poettering: Revisiting how we put together Linux systems by nix
Parent article: Poettering: Revisiting how we put together Linux systems

"What I really want -- and still seems not to exist -- is something that gives you the POSIXness of local filesystems"

What exactly are you missing?

"not needing to make a new filesystem or move things around madly on the local machine just in order to export the fs. I know, this property is really hard to retain due to the need to make unique inums on the remote machine without exhausting local state"

I'm not sure I understand that description of the problem. The problem I'm aware of is just that it's difficult to determine given a filehandle whether the object pointed to by that filehandle is exported or not.

"NFS doesn't quite get it right"

Specifically, if you export a subtree of a filesystem then it's possible for someone with a custom NFS client and access to the network to access things outside that subtree by guessing filehandles.

Poettering: Revisiting how we put together Linux systems

Posted Sep 8, 2014 15:55 UTC (Mon) by nix (subscriber, #2304) [Link] (3 responses)

On the POSIXness side of things, I'd like the atomicity guarantees you get from a local fs, rather than having just rename() be atomic; I'd like to not have to deal with silly-rename leaving spew all over my disks that it is hard to figure out when it is safe to clean up; I'd like the same ACL system on the local and the remote filesystems rather than its being mapped through a crazy system designed to be interoperable with Windows... oh, and decent performance would be nice (like NFSv4 allegedly has, though I haven't yet managed to get NFSv4 to work -- haven't tried hard enough, I think its requirements for strong authentication are getting in my way).

Clearly NFS can't do all this: silly-rename and the rest are intrinsic to (the way NFS has chosen to do) statelessness. So I guess we need something else.

As for the not-quite-rightness of NFS's lovely ability to just ad-hoc export things, I have seen spurious but persistent -ESTALEs from nested exports and exports crossing host filesystems in the last year or two, and am still carrying round a horrific patch to make them go away (I was going to submit it, but it's a) horrific and b) I have to retest and make sure it's actually still needed: the underlying bug may have been fixed).

Poettering: Revisiting how we put together Linux systems

Posted Sep 8, 2014 16:30 UTC (Mon) by rleigh (guest, #14622) [Link] (1 responses)

At least with NFSv4 and ZFS, ACLs are propagated to client systems just fine (it's storing NFSv4 ACLs natively in ZFS on disk). For a combination of FreeBSD server and client at least. With a FreeBSD server and Linux client, NFSv4 ACL support isn't working for me, though the standard ownership and perms work correctly. I put this down to the Linux NFS client being less sophisticated and/or buggy, but I can't rule out some configuration issue.

Poettering: Revisiting how we put together Linux systems

Posted Sep 8, 2014 18:49 UTC (Mon) by bfields (subscriber, #19510) [Link]

With a FreeBSD server and Linux client, NFSv4 ACL support isn't working for me, though the standard ownership and perms work correctly. I put this down to the Linux NFS client being less sophisticated and/or buggy, but I can't rule out some configuration issue.

The actual kernel client code is pretty trivial, so the bug's probably either in the FreeBSD server or the client-side nfs4-acl-tools. Please report the problem.

Poettering: Revisiting how we put together Linux systems

Posted Sep 8, 2014 18:46 UTC (Mon) by bfields (subscriber, #19510) [Link]

I think its requirements for strong authentication are getting in my way

The spec does require that it be implemented, but you're not required to use it. If you're using NFS between two hosts with a recent linux boxes then you're likely already using NFSv4. (It's default since RHEL6, for example.)

silly-rename and the rest are intrinsic

See the discussion of OPEN4_RESULT_PRESERVE_UNLINKED in RFC 5661. It hasn't been implemented. I don't expect it's hard, so will probably get done some time depending on the priority, at which point you'll no longer see sillyrenames between updated 4.1 clients and servers.

spurious but persistent -ESTALEs from nested exports and exports crossing host filesystems

Do let us know what you figure out (linux-nfs@vger.kernel.org, or your distro).