3 ms·

My bias shows here, but what's your alternative to NFS from *nix? We used AFS at school. I suppose you could keep your data locally and be responsible for your

My bias shows here, but what's your alternative to NFS from *nix? We used AFS at school. I suppose you could keep your data locally and be responsible for your own backups / use version control as backups.

beagle3 7y ago
CIFS / SMB ; Client is in most kernels these days, server (Samba) is easy to install and use. In my experience performance is acceptable (that is, I'm getting >110MB/s on a 1Gb connection), locking semantics if you need them work much better than an NFS - and most importantly, it doesn't hang as bad when a server goes away (NFS behaves like it's 1980 in that respect - the recommended and only consistent way to unhang processes when the server goes away is, I kid you not, start a local NFS server on the client, and add the IP address of the server locally to the client; Then, one of the retries will get an error from the local server, at that point you can deal with it, shutdown the local NFS and remove the extra IP address)
- pfranz 7y ago
  I'm actually curious to try that next time it comes up, but with automount + NFSv3 if a server goes down and isn't expected to come back up I can 'umount -l' and kill the hung process. With CIFS/SMB throughput wasn't the issue, but dealing with small files seemed to be. With NFS most places served software packages off of it and whenever this was tried with SMB it was unreasonably slow. I'm ignorant enough at the implementation that I could believe this was a configuration thing.
  - beagle3 7y ago
    > I can 'umount -l' and kill the hung process. I don't use automount, but unless automount does some crazy magic ... this doesn't really help; umount -l (or umount -lf) indeed removes the mountpoint from the filesystem (so no new processes can access it and get stuck), but the kernel thread is still stuck waiting for an answer that will never come, and many processes cannot be killed even with "kill -9".
    - pfranz 7y ago
      You are right. In practice it generally works for our needs--I haven't looked deep enough at the problem to defend every reason why. With the mount in place, things like 'df' hang indefinitely, whereas once they're unmounted people can work again. I think automount is doing a lot of the heavy-lifting here because I guess next time you navigate there it notices the NFS server is down and returns an error instead of hanging the new process. Usually, whatever old process that is hanging onto the mount gives up or dies. If not, often a "kill -9" takes care of it. I have had these processes get stuck indefinitely. I was usually doing something stupid. For example, mounting a USB drive over NFS for a user. They got trigger-happy and pulled the USB drive without unmounting it or informing anyone. Effectively, I just considered that mount point "burned" on the client until I could reboot. I'm not sure how other people use network mounts. In general, they're expected to be up and any changes or removals will be part of a maintenance window. Changes would go through a series of steps to avoid this scenario. Sure, it's a bit of a pain, but doesn't seem to unreasonable in practice (stop new mounts, kill existing processes/mounts, update). My experience has mostly been with NFSv3, for all I know newer versions address this better.

beagle3 7y ago

CIFS / SMB ; Client is in most kernels these days, server (Samba) is easy to install and use. In my experience performance is acceptable (that is, I'm getting >110MB/s on a 1Gb connection), locking semantics if you need them work much better than an NFS - and most importantly, it doesn't hang as bad when a server goes away (NFS behaves like it's 1980 in that respect - the recommended and only consistent way to unhang processes when the server goes away is, I kid you not, start a local NFS server on the client, and add the IP address of the server locally to the client; Then, one of the retries will get an error from the local server, at that point you can deal with it, shutdown the local NFS and remove the extra IP address)

pfranz 7y ago
I'm actually curious to try that next time it comes up, but with automount + NFSv3 if a server goes down and isn't expected to come back up I can 'umount -l' and kill the hung process. With CIFS/SMB throughput wasn't the issue, but dealing with small files seemed to be. With NFS most places served software packages off of it and whenever this was tried with SMB it was unreasonably slow. I'm ignorant enough at the implementation that I could believe this was a configuration thing.
- beagle3 7y ago
  > I can 'umount -l' and kill the hung process. I don't use automount, but unless automount does some crazy magic ... this doesn't really help; umount -l (or umount -lf) indeed removes the mountpoint from the filesystem (so no new processes can access it and get stuck), but the kernel thread is still stuck waiting for an answer that will never come, and many processes cannot be killed even with "kill -9".
  - pfranz 7y ago
    You are right. In practice it generally works for our needs--I haven't looked deep enough at the problem to defend every reason why. With the mount in place, things like 'df' hang indefinitely, whereas once they're unmounted people can work again. I think automount is doing a lot of the heavy-lifting here because I guess next time you navigate there it notices the NFS server is down and returns an error instead of hanging the new process. Usually, whatever old process that is hanging onto the mount gives up or dies. If not, often a "kill -9" takes care of it. I have had these processes get stuck indefinitely. I was usually doing something stupid. For example, mounting a USB drive over NFS for a user. They got trigger-happy and pulled the USB drive without unmounting it or informing anyone. Effectively, I just considered that mount point "burned" on the client until I could reboot. I'm not sure how other people use network mounts. In general, they're expected to be up and any changes or removals will be part of a maintenance window. Changes would go through a series of steps to avoid this scenario. Sure, it's a bit of a pain, but doesn't seem to unreasonable in practice (stop new mounts, kill existing processes/mounts, update). My experience has mostly been with NFSv3, for all I know newer versions address this better.