3 ms·

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' an

by 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.

by pfranz 7y ago

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.