Rsync --link-dest and ext3: can I increase the number of inodes?
cs at zip.com.au
Tue Sep 23 00:00:54 UTC 2008
On 22Sep2008 09:51, Theodore Tso <tytso at mit.edu> wrote:
[...snip a lot of remarks I entirely agree with...]
| > But a database is... more complicated [...]
| Sure, but the solution may not scale so well for folks who are backing
| up 50+ machines and backing up all of /usr, including all of the
| distribution maintained files, or for folks who never delete any of
| their past incremental backups.
Sure. There's plenty of stuff I wouldn't back up this way.
| > For Richard's benefit, I can report that I've used the hard link backup
| > tree approach extensively on ext3 filesystems made with default mke2fs
| > options (i.e. no special inode count size) and have never run out of
| > inodes. Have you actually done some figuring to decide that running out
| > of inodes is probable?
| Sure, but how many machines are you backing up this way, and how many
| days of backups are you keeping?
My own current use case is pretty small, and they're not machines but
data trees (eg static web site trees, configuration files etc - they
have well defined and simple permissions and usually low change rates
so I don't need "machine image" quality, just data integrity).
Some 10s of GB and 4 months of dailies; I do prune old trees, but for
overall disc space reasons, not lack of inodes.
Only half of this is on ext3; the other is on xfs which I think has dynamic
Probably we need to know more about Richard's plans.
| And have you ever tried running
| "e2fsck -nftt /dev/hdXX" (you can do this on a live system if you
| want; the -n means you won't write anything to disk, and the goal is
| to see how much memory e2fsck needs) to make sure you can fix the
| filesystem if you need it?
I'll queue this up as something to try, though the backups themselves
are replicated to elsewhere anyway.
Cameron Simpson <cs at zip.com.au> DoD#743
More information about the Ext3-users