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
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 10:19:47 EST