The file in question is /var/log/lastlog. I did some googling around and found a number of entries on this topic. It turns out this is a spare file and it's reported size is much larger than it's actual size - however most references declare it to be 18M not 1.2T. It also turns out that this is a brand new RHEL4 installation.
Further digging reveals that the size of lastlog (not it's physical allocation) is actually equal to the largest user's UID * 292. For some reason, on my system the UID of nfsnobody was set to 4294967294. RHEL4 being a pretty new version, this feels like a bug that hasn't been discovered yet.
My next check was to see if there is a switch on rsync to have it deal better with sparse files and it turns out if does and SI already uses that switch. I also found the rarely used (at least by me) --sparse=always switch on the cp command. But when I try copying lastlog with that switch, it hangs just like rsyc does. I suspect that both rsycn and cp have to read through the file to figure out which bytes are indeed null and don't need to be actually copied. I do admit that I didn't wait more than a couple of minutes before ^C-ing it
So the bottom line is I'm going to manually exclude /var/log/lastlog when I do my 'getimage', but also felt the need to write this note and at least forewarn people about this situation and see if anyone knows why the UID of 'nfsnobody' is so big.
-mark
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Sisuite-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sisuite-users
