Hacker News Reader

Comment by eqvinox | Hacker News Reader

Have you run any POSIX compliance checks against it? In particular, how are you handling assignment of inode numbers (fileid in NFS speak) to "virtual" files and making sure those stay reasonably consistent? (I vaguely remember this being a bit of a tripwire)

Also did you look at NFSv4 / what made you decide to go with NFSv3? My (superficial) impression was that NFSv4 did a lot of simplifying and throwing out legacy stuff (e.g. rpcbind), but I don't know too many details on this…

[edit: NFSv4 answered on parent / https://news.ycombinator.com/item?id=37575304 ]

FWIW I think NFSv4 would be a rewrite rather than an extension :D

View on HN

I tested by uh... building a "mirrorfs" and compiling this project in it :-) (cargo does stress it pretty hard). I have not looked for POSIX compliance testers. Is there one you can point me to?

NFSv4 did throw out a lot of the legacy stuff, but also added a bunch of other state information like locks and delegation which is quite a bit more annoying to implement. Technically cos this is meant for "localhost-mounting-only", delegation should be easy to build (since we are expecting only exactly 1 mount). But v3 had far fewer APIs to implement, and so is a good starting point.

There's https://github.com/google/file-system-stress-testing but in this case I believe it would mostly stress-test the NFS client rather than your code… and I have never tried to use it, no idea if it even does anything useful.

I know from lore that there are compliance-test suites for the POSIX file system API, but I believe those are commercial products :(

xfstests is very thorough and reusable beyond xfs.

Note that there’s absolutely no requirement to support more advanced features such as locking and delegations. Even if a client offers to accept a delegation, a server may just deny/ignore it as part of OPEN.

If I may ask, is this mirrorfs available somewhere? The demofs from nfsserve seems to create and server a pure in-memory fs tree if I read the sources correctly.

NFSv4 is a completely different protocol and basically doesn't share anything with v2/v3. While technically it's still implemented using Sun RPC, it only has two procedures: NULL and COMPOUND. Version 3 is actually an RPC protocol, with a different procedure for each filesystem operation (READ, WRITE, CREATE, ...). One of the genius moves that Sun made with NFS was to distribute the protocol files (rpcgen) which autogenerate stubs (in C) making it easy to implement servers and clients. Nothing like that exists for v4.

Look at RFC 7531. XDR definitions for NFSv4 exists, and they can also be used to generate C bindings if you want.

Sure, running it through rpcgen generates bindings for both RPCs, NULL and COMPOUND:

    /// /*
    ///  * Remote file service routines
    ///  */
    /// program NFS4_PROGRAM {
    ///         version NFS_V4 {
    ///                 void
    ///                         NFSPROC4_NULL(void) = 0;
    ///
    ///                 COMPOUND4res
    ///                         NFSPROC4_COMPOUND(COMPOUND4args) = 1;
    ///
    ///         } = 4;
    /// } = 100003;

Which is also what you want, right? The issue is that with compound calls there is some state that’s carried over between operations (current/saved file handle), so you’d need to implement that yourself anyway.

Well yeah that's the difference, it doesn't generate the state machine for you so you "just" need to implement it yourself. For v3, rpcgen spits out a working function that you link into your program and you're done (on the client side anyway). Much easier.

Reply on news.ycombinator.com