Thanks to everyone who replied to my question regarding ndmpcopy versus vol copy when migrating from a F740 to a F820! Based on the recommendations, we've done a level 0 ndmpcopy and two increasing incrementals (level 1 and level 2). On what was to be 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?
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!
Dawn Lovell dlovell@centurytel.net
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
On Thu, 25 Oct 2001, Steve Losen wrote:
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.
Thanks for your help! I don't know to which filer the inode belonged, but my endless find was running on the source. I should have mentioned that we're running 5.3.6R2 on the source filer and 6.1.1R1 on the target filer.
I called back into tech support regarding the error; it turns out that my call was originally logged as a block inconsistency instead of the ndmpcopy inconsistent dumpmap error. I just received a very helpful message that basically said that it would be safe to ignore the inconsistent dumpmap message.
It was evidently a result of the dumpmap and the actual directory structure disagreeing, i.e., a file existed in the directory that the dumpmap didn't show. The process goes with what the directory has, so the message is more of a FYI than an error. I'm very loosely paraphrasing here, since I don't want to post someone's email without their permission. Please don't blame NetApp for any misstatements I make.
Thanks to everyone for their assistance! This list and its archives are such helpful resources. I particularly enjoyed the faceplate color discussion, especially after seeing the truly unique shade of green on the 820s. :-)
Dawn Lovell dlovell@centurytel.net
-
Dawn Lovell -
Steve Losen