On 10/11/99 07:41:30 you wrote:
The volume could be offline, that's for sure, but why the machine ?
This is the result of a less-than-thorough multivolume implementation plan. Originally, there only *was* one volume, so taking the whole filer down wasn't an issue. Presumably when mutlivolume was to be implemented, Netapp decided it was more important to get that out the door than to spend more time and resources modifying a better wack interface to run on an offline volume while the system remained up.
Note that this is also different from a request for a completely online wack on an active filesystem, or allowing a filesytem to remain online read-only while being wacked. I still question the utility of the latter, but it might be good as part of an automated process strategy (just as snapshots are created for dump). Anyway, these are all very different enhancements. Netapp will have to decide which ones to implement, and which ones to implement first.
Bruce
The volume could be offline, that's for sure, but why the machine ?
I'll note here to others unfamiliar that this is similar to what the Auspex will do.
I forget the exact terms, but an inconsistent FS on an Auspex is placed into a mode where NFS requests to the FS are queued and not acted upon.
Meanwhile, the 'head' can do a normal fsck on the FS. Note the FS is never unexported. After the FS passes the fsck, it can be brought back online, and all queued NFS requests are acted upon.
Obviously this is only one implementation, but I liked it when I first ran into it. I'm sure given enough resources NetApp could produce something similar. The question is where something like this is on their strategic plans.
I've seen this happen on an Auspex, but never yet on a NetApp. What does happen on a running system when there's a FS error? Does the server crash or anything? Do you get a warning?
-
Arthur Darren Dunham -
sirbruce＠ix.netcom.com