My rsnapshot has been working very well (with occasional but understandable
glitches) for several years.
But it also stopped working recently, reporting errors which trace back to
'cp -al' failing with files with nearly 32000 hard links. So, this thread
certainly got my attention.
Helmut's suggestion of looking at the inode link count proved the crucial
piece for me. Thanks. Error logs also pointed in the right direction:
/bin/cp: cannot create link `//snapshots/hourly.1/foo': Too many links
and discovering and 'foo' had exactly 32000 links.
I don't know what the resolution was of the original poster, but in my case
the problem lay outside of cp, rsnapshot, and rsync. Instead, it was a
consequence of my attempt to squeeze space in my archive by using a
hardlink merge script. I had reasonable luck with William Stearns'
freedups.pl, but it tripped on some unusual directory name created on a
network store by a Mac OSX user and so I moved to Zygo Blaxell's more
recent faster-dupemerge script which seemed to be working without a fault.
By my analysis, it is also blameless. It's just the task I ask it to
perform runs up against the 32000 maximum in due course.
We started allowing Mac OSX machines on our network and that turned out to
be the problem (in many ways, but I won't go there). On the Linux ext3
file system, the resource forks of the OSX files are stored as well as the
data files and several users' home directories are now littered with a
'._foo' resource fork file for each 'foo' data file. Almost all of these
resource fork files are empty placeholders, yet non-zero. A typical Mac
user has 3000-6000 of these! The hard-link merge scripts dutifully merge
identical files, the result of which is that, post merge, there are many
files with link counts well over 1500. And that is just by merging within
users' individual directories. If I merged across user directories, the
link counts would be far higher.
Multiply the 1500 by the number of snapshot levels you have and it is easy
to see how thing just break after a certain period of time. I have 4
hourly snapshots each day, so by my calculations things fall apart in month
8 where the 22nd snapshot is created.
The solution for me is to do less hard link squashing of identical files
(i.e. use more disk space) or use a merging script which knows how to skip
small files.
Summary: if you do post-processing of your snapshots by hard-linking
together identical files you may encounter the 'Too many links' error from
cp or the suggestion 'Perhaps your cp does not support -al options?'
Regards,
--Carl Boe
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
