our last incremental (level 3) with the source filesystem read-only, we received the following message:
newfiler: LOG: RESTORE: newfiler: LOG: Inconsistent dumpmap on inode 10831660.
The copy goes on to complete successfully, but I'm concerned about the impact of this. I'm running a find to try to locate the file or directory with that inode, but it's going to run forever with the number of files we have. Is there a faster way than find to match the inode to a file?
I don't know of any way other than find. If you have a convenient way to split the search into multiple directory trees, then try running 10 or more finds concurrently. We have a user home directory tree with over 4 million files that is split into 26 sub directories, one for each letter of the alphabet. I routinely run 26 finds in parallel and can chug through this in less than an hour.
Before launching off on a find expedition, is it clear from the error message which filer the inode is on? ndmpcopy does not preserve inode numbers, so they are all different on the target filer. My guess is the number is from the old filer, so you need to look there.
Does anyone know if this is a serious error? I'd thought that it was probably the result of a file on the target filesystem being changed outside of the ndmpcopy process. That shouldn't have happened, but it's certainly possible. I called NetApp support about this, however, and was told that it was a filesystem problem on the target filer and that we should bring it down and run wafl_check.
I can't find the error in the archives or on the NOW site, so I would greatly appreciate any insight. Thanks for your time!
I wouldn't worry about this error too much and I highly doubt that your new volume is corrupt and needs a wafl_check. You didn't say what version of ONTAP you are using, but I can tell you from my own personal experience that incremental restore has a long history of bugginess. I would bet that this error is just restore weirdness and not a filesystem problem. Still, it wouldn't hurt to find the file mentioned in the error message and verify that it was copied.
Steve Losen scl@virginia.edu phone: 434-924-0640
University of Virginia ITC Unix Support