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

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/