OK. I had a couple of quick points to add.
1) Maybe it isn't such a _bad_ thing not to be able to see the data from the machines on which it's mounted. After all, restore would not appreciate somebody modifying the file system it is working on filling in. It won't crash your machine on anything like that, but still... Also, since directory permissions aren't restored until the very end of a restore, one could see that as a serious security hole, as well.
2) Restore should really do a bit more than sit there, and maybe ask for a new tape every once in a while. There should definitely be some hints that it's working for you.
3) If you have problems like this, do you guys call NetApp and ask for a bug to be filed. If there are bugs with actual customer call records, those are (obviously) treated as being more serious than, say, bugs that I file. So, I have filed a bug on restore being too quiet. It is filed as 9677, but it will take some time before it is visible on NOW.
Regardless, you should open a call record on this bug to make it more visible to the powers that be.
In the future, if you have problems with dump and restore, it would be great if you made sure tech support opened bugs on them. I try to listen on toasters, but I miss things... And please don't mail me asking me to file a bug. I'm not volunteering for that at all. They already make me do the windows in addition to dump and restore.
4) Why doesn't restore lay down some framework when it first starts? In the classic BSD dump scenario, this is how things work (ufsdump, dump on Linux, etc)
Restore reads the directories from tape into one huge file. It uses this create a desiccated filesystem. That is to say, it tracks the offsets of the beginning of each directory in this file. So, when a user asks for a file, it can execute its own namei, without ever laying this directory structure on the FS. This saves quite a bit of space.
Aside: [Of course, you ask, why do this? Remember that restore -x and restore -i on non-Netapp systems) only extract part of the data on tape. Thus, to make the whole directory structure on the system is a bad idea, especially on a system light on disk space.]
Then, it calculates which files need to be extracted. Finally, it begins to lay the directories and files on the system. But to get to this point takes quite a bit of time. After the directories and files have been written to tape, the system begins to restore the directories' permissions and times [we couldn't do this when creating the directories, since creating the files _might have failed_ due to permission problems and _definitely_ would have affected the times.]
Note, none of this proprietary. It's all in the freely available BSD code. (Just making sure marketing doesn't yell at me again. ;)
So, there are ways to improve on this scheme, and we're working on those. But for now, the reason you don't immediately see lots of data on the system is that the directory data is all in one huge temporary file.
OK. Back to those windows.
Stephen Manley The Restore-Man Formerly the Dump-Man