| 1 |
On Wed, Feb 17, 2016 at 2:01 PM, Andrew Savchenko <bircoph@g.o> wrote: |
| 2 |
> 1) NFS v4 shares can't be unmounted if server is unreachable (even |
| 3 |
> with -f). If filesystem (e.g. /home or /) contains such unmounted |
| 4 |
> mount points, it can't be unmounted as well, because it is still in |
| 5 |
> use. This happens quite often if both NFS server and client are |
| 6 |
> running from UPS on low power event (when AC power failed and |
| 7 |
> battery is almost empty). |
| 8 |
|
| 9 |
Perhaps at least the behavior in this case should be configurable |
| 10 |
(timeouts, infinite or otherwise). |
| 11 |
|
| 12 |
If you can't contact a remote nfs server then I believe it is possible |
| 13 |
that unwritten changes are in buffers/etc. Depending on circumstances |
| 14 |
I could see either pausing until the server comes back or discarding |
| 15 |
changes and powering off could either be the appropriate behavior. |
| 16 |
|
| 17 |
Ultimately, anything not on the disk is always at risk, and any |
| 18 |
filesystem needs to provide for unclean shutdown to be truly robust. |
| 19 |
A kernel panic/etc could cause loss of all data in buffers without |
| 20 |
warning. However, barring that we should of course engineer openrc to |
| 21 |
shut down in the most clean manner possible, and this should include |
| 22 |
read-only mounts for anything which can't be unmounted. |
| 23 |
|
| 24 |
And even systemd+dracut struggles to cleanly unmount NFS roots in the |
| 25 |
versions I'm running at least, so that is an edge case that doesn't |
| 26 |
get much testing. |
| 27 |
|
| 28 |
-- |
| 29 |
Rich |
Archives