I will comment on your excellent suggestions below, but first, I
should point out that the problem is moot, as the disk in question is
nearly full. I ran out of inodes only shortly before running out of
space. So it's time for a new disk anyway. And now on to your
On Apr 24, 2009, at 8:05 PM, David Keegel wrote:
> (1) try seeing if there are duplicated files in the snapshot root
> and if
> so hard link them together. On Linux there is a program called
> which will hard link together duplicated files under a given
> It looks like there are programs in /usr/ports/sysutils for FreeBSD.
The tool does exist in FreeBSD ports, but I haven't tried it yet. If
hard links (within a snapshot) don't exist in the source, I'd be
reluctant to add them to the back-up since a complete restore from the
back-up might lead to links that I don't want or expect.
> (2) [long shot] try running "tunefs -f 1024 /dev/..." and see if that
> makes any difference.
That is a very interesting idea. Naturally, I'd looked at the man
page for tunefs before my original post, but it hadn't occurred to me
that reducing the "expected" file size (which is tunable) might
increase the number of inodes. When I get a chance, I will experiment
with that on a test file system, as the disk in question is going to
go into the archives.
> (3) remove some old snapshots (although the problem is likely to come
> back, unless the problem was just because your old snapshots were not
> hard linked together properly, or unless you reduce what you retain).
I do need to better consider my retention policy with disk size. I
had under estimated the size of the disk that I would need in the
first place. Partially it is because I went from tracking the
"RELEASE" versions (which change infrequently) of FreeBSD to tracking
STABLE which change pretty much as frequently as I wish to rebuild the
OS. Also the differences between a pair of weeklies is far greater
than the difference between a pair of hourlies.
One thing that I did do (and recommend) to others for saving space on
backups: If you backup log files, use dates in the filenames of
rotated log files. So instead of having a distinct maillog.2.gz each
day have the rotated log files be maillog.20090420.gz so that it will
be a single (hardlinked) file on all backups. I haven't done this
with all logs, but I've done it with most. Naturally, this also makes
recovery of log files easier. I'm actually not building this into log
rotation, but using syslog-ng to save the logs in dated files. OF
course, if you don't back up logs, than this isn't an issue.
> (4) rsnapshot-copy the backups to some other temporary space, then
> rebuild the file system with something like newfs -i 4096 (or 1024).
> If you're doing this, it's probably worth dividing the number of
> kilobytes used currently by the number of i-nodes used currently
> on that file system to get an estimate of the current average file
> size, and make sure the -i number you use is less than that.
Thank you. That is a great suggestion for when I set up my new disk/
filesystem. Although I ran out of inodes only slightly before running
out of disk space, I would prefer it to be the other way round. (I
have systems in place for checking available disk space, but haven't
been monitoring inodes, so would prefer to run out of disk first.)
> It would probably be worth checking whether there are less hard links
> in your backups than there should be. Some old versions of rsnapshot
> had bugs where with certain config combinations, hard links would not
> be made properly between snapshots. But this shouldn't be a problem
> with rsnapshot 1.3.1 (as far as we know!)
I really don't think that there are. When I first starting running
rsnapshot, I was very careful to check that the rsync was doing the
right thing. (It's something that I consider way cool, and wanted to
see it in action.)
Jeffrey Goldberg http://www.goldmark.org/jeff/