4 ms·

Hi! Author here. Happy to answer any questions!

by ylow 3y ago

ReactiveJelly 3y ago
> You simply need to implement the vfs::NFSFileSystem trait. Wait, what...... .. So not only is it an easy-to-run Rust NFS server and client (I gave up on NFS some years ago because I couldn't figure out how to run Samba) but it's also meant to use as a _substitute_ for FUSE in stacks like SSHFS or an app wanting to serve debug data as files? Awesome!
- eqvinox 3y ago
  I don't think this includes a client, in fact the post argues that not having to implement the client because it already exists in the kernel was a major benefit of the approach…
- ylow 3y ago
  Exactly. You build the server-side (as a FUSE alternative), and just use the OS's NFS client to mount it.
  - inferiorhuman 3y ago
    Sweet! I've been monkeying around with writing an HFS interpreter (in rust ofc). Unfortunately 'fuser' is less than ideal on a Mac. This could be an interesting alternative. Edit: Oh. It's async. The other bit that I liked from fuser: the default implementations in the trait cut down on the boiler plate. Setting the RO mount option got you defaults that DTRT.
    - ReactiveJelly 3y ago
      You can interoperate async and threads, but yes you have to tolerate having Tokio or similar as a dep
lukax 3y ago
This library is amazing. Also very happy to see such a permissive license. Btw, why did you decide to use NFS instead of WebDAV? WebDAV should be easier to implement and is also supported on all platforms.
- ylow 3y ago
  I have not looked at WebDAV closely. I was looking for something that is already supported in all the major operating systems without additional libraries. I don't believe WebDAV is commonly supported out of the box?
  - eqvinox 3y ago
    WebDAV on Linux works over drumrull FUSE :D
  - lukax 3y ago
    WebDAV is supported by Windows, MacOS and Linux. On all platforms you can mount it without admin/sudo (`net use` on Windows, `mount_webdav` on macOS and `gio mount` on Linux). Here is official Go package[1] using which you can implement your own WebDAV server (you only need to implement your FS interface). [1] https://pkg.go.dev/golang.org/x/net/webdav https://pkg.go.dev/golang.org/x/net/webdav
    - ylow 3y ago
      Interesting. I do not know much about webdav. Great to learn something new! Will take a look.
eqvinox 3y ago
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 https://news.ycombinator.com/item?id=37575304 ] FWIW I think NFSv4 would be a rewrite rather than an extension :D
- ylow 3y ago
  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.
  - eqvinox 3y ago
    There's https://github.com/google/file-system-stress-testing 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 :(
  - ianlevesque 3y ago
    xfstests is very thorough and reusable beyond xfs.
  - EdSchouten 3y ago
    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.
deleted 3y ago
[deleted]
hn92726819 3y ago
I believe you can install an NFS client on windows home if you just go to programs and features > add a feature > NFS client, but I don't have a way to check. The fact you just need to impl one trait is amazing. I will definitely be testing this out
- hn92726819 3y ago
  You're right, there is no way to do it in windows home edition

Hi! Author here. Happy to answer any questions!

by ylow 3y ago

Hi! Author here. Happy to answer any questions!

> You simply need to implement the vfs::NFSFileSystem trait. Wait, what...... .. So not only is it an easy-to-run Rust NFS server and client (I gave up on NFS some years ago because I couldn't figure out how to run Samba) but it's also meant to use as a _substitute_ for FUSE in stacks like SSHFS or an app wanting to serve debug data as files? Awesome!

eqvinox 3y ago
I don't think this includes a client, in fact the post argues that not having to implement the client because it already exists in the kernel was a major benefit of the approach…
ylow 3y ago
Exactly. You build the server-side (as a FUSE alternative), and just use the OS's NFS client to mount it.
- inferiorhuman 3y ago
  Sweet! I've been monkeying around with writing an HFS interpreter (in rust ofc). Unfortunately 'fuser' is less than ideal on a Mac. This could be an interesting alternative. Edit: Oh. It's async. The other bit that I liked from fuser: the default implementations in the trait cut down on the boiler plate. Setting the RO mount option got you defaults that DTRT.
  - ReactiveJelly 3y ago
    You can interoperate async and threads, but yes you have to tolerate having Tokio or similar as a dep

lukax 3y ago

This library is amazing. Also very happy to see such a permissive license. Btw, why did you decide to use NFS instead of WebDAV? WebDAV should be easier to implement and is also supported on all platforms.

ylow 3y ago
I have not looked at WebDAV closely. I was looking for something that is already supported in all the major operating systems without additional libraries. I don't believe WebDAV is commonly supported out of the box?
- eqvinox 3y ago
  WebDAV on Linux works over drumrull FUSE :D
- lukax 3y ago
  WebDAV is supported by Windows, MacOS and Linux. On all platforms you can mount it without admin/sudo (`net use` on Windows, `mount_webdav` on macOS and `gio mount` on Linux). Here is official Go package[1] using which you can implement your own WebDAV server (you only need to implement your FS interface). [1] https://pkg.go.dev/golang.org/x/net/webdav https://pkg.go.dev/golang.org/x/net/webdav
  - ylow 3y ago
    Interesting. I do not know much about webdav. Great to learn something new! Will take a look.

eqvinox 3y ago

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 https://news.ycombinator.com/item?id=37575304 ] FWIW I think NFSv4 would be a rewrite rather than an extension :D

ylow 3y ago
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.
- eqvinox 3y ago
  There's https://github.com/google/file-system-stress-testing 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 :(
- ianlevesque 3y ago
  xfstests is very thorough and reusable beyond xfs.
- EdSchouten 3y ago
  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.

deleted 3y ago

[deleted]

hn92726819 3y ago

I believe you can install an NFS client on windows home if you just go to programs and features > add a feature > NFS client, but I don't have a way to check. The fact you just need to impl one trait is amazing. I will definitely be testing this out

hn92726819 3y ago
You're right, there is no way to do it in windows home edition