Tom,
What you are missing here is that the client uses two things to access
content on
the servers - path and file handles. When you do the reshare, you
would be pointing any
new requests to the empty directories. But, any application which
already had a
file handle would have a reference to the old mount (via the fsid part
of the file handle).
OK thanks for the precisions. It's why I'm getting those errors :
Sep 1 15:12:53 varan-14 kernel: [3424547.256518] NFS: server
filer-large-vip.local error: fileid changed
Sep 1 15:12:53 varan-14 kernel: [3424547.256518] fsid 0:13: expected
fileid 0x2, got 0x41
The options I see are to:
1) Shutdown NFS/remove write access to the export/etc - this is along
the lines of what
you have done. And the result is that the server will inform the
client of an error.
2) Disconnect the servers from the network. (Or partition the
network). In this scenario,
the client will be getting timeouts and will probably use a retry schema.
3) Shutdown the NFS clients - harsh, but they will not be accessing
the servers and you
can easily do the upgrades.
These all result in downtime for both your servers and your clients.
So in short there is no way to do a maintenance on attached storage,
could it be hard drives, RAID, iSCSI or anything.
Is such a "feature" in the roadmap ?
--
Greg
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
