From: Holger P. <wb...@pa...> - 2011-10-03 02:49:07
|
Hi, Mike Dresser wrote on 2011-10-02 21:26:05 -0400 [Re: [BackupPC-users] Fairly large backuppc pool (4TB) moved with backuppc_tarpccopy]: > On Mon, 3 Oct 2011, Holger Parplies wrote: > > This was on the *old* pool, right? > > I thought it was. But now that I look again and they're all showing 2 on > the nlink.. I think I'm losing my marbles, or I was looking at the new > pool. Sorry! well, the reason I asked was that for the *new* pool the link count would be 1 (because the files were copied rather than linked, because BackupPC_tarPCCopy didn't know where to link to), whereas for the old pool, like Jeffrey, I was having a hard time imagining how that would happen. Well, there were three ideas: 1.) Bug in BackupPC_link - didn't seem likely. 2.) Bug in BackupPC_nightly - likewise. 3.) MakeFileLink errors due to incorrect installation (pool/ and pc/ on different FSes or strange softlinking confusing BackupPC). Possible, but you seem to know what you're doing, so I wasn't expecting that either. It's just much easier to imagine a file getting linked into the pool with an incorrect pool file name than it not getting linked into the pool at all. > Now that I know there's an nlink >1 for that file, I'll let it go through > for the couple days it'll take to find that inode. You might want to use parts of either Jeffrey's or my script. Jeffrey builds a "pool" of information which files use which inode. I build a file with pretty much the same information. Both don't need to be stored on the pool FS they refer to (because they're not links to content, they're files with information). That way, you could iterate over the pool *once* and reuse the information multiple times. My method has the downside that you need to sort a huge file (but the 'sort' command handles huge files rather well). Jeffrey's method has the downside that you have an individual file per inode with typically probably only a few hundred bytes of content, which might end up occupying 4K each - depending on file system. Also, traversing the tree should take longer, because each file is opened and closed multiple times - once per link to the inode it describes. Actually, a single big file has a further advantage. It's rather fast to look for something (like all non-pooled files) with a Perl script. Traversing an "ipool" is bound to take a similar amount of time as traversing pool or cpool will. > > I agree with Jeffrey, if there is a bug out there, I'd be interested in > > hunting it down :). But first, we should try to make sure that the cause of > > this attrib file strangeness is really within BackupPC. > > And not the idiot operator who was looking at the wrong pool? :) Well, no. I was thinking the same as Jeffrey - a single failed BackupPC_link would produce many files not linked into the pool (whether or not due to an operator mistake). But, ultimately, yes, it *is* easy to get something like that wrong - it's certainly happened to me before - and there's not much point in looking for a bug in the wrong parts of the code. In particular, we can't find out if, when, and how a pool link disappeared, while the incorrect md5sum may well give hints as to what went wrong. Regards, Holger |