FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > EXT3 Users

 
 
LinkBack Thread Tools
 
Old 09-22-2008, 02:27 AM
Theodore Tso
 
Default Rsync --link-dest and ext3: can I increase the number of inodes?

On Sun, Sep 21, 2008 at 08:44:57PM -0400, Richard Michael wrote:
> (I run rsync --link-dest backups onto ext3 and am anticipating running
> out of inodes.)
>
> Is there a tool I can use to increase the number of inodes on an ext3
> filesystem?

Not without backing up your data to tape/DVD/whatever, reformatting
the filesystem, and restoring from backups, sorry.

> Also, are there any other implications I should be aware of when using
> rsync in this way on ext3? Specifically, what became of this discussion
> related to e2fsck and memory use?
>
> https://www.redhat.com/archives/ext3-users/2007-April/msg00017.html

This is still a problem, and it's pretty fundamental to how e2fsck
works. Calculating the number of hard links so we can make sure that
i_links_count is correct requires a large amount of memory; there's no
getting around that. E2fsck has a short-cut optimization that works
for the common case where i_links_count=1, but that's not true if you
are using backup strategies such as rsync --link-dest. The solution
described above is present in mainline e2fsprogs, as an emergency
method of allowing e2fsck to fix broken filesystems, but if you have
to resort to it, it's *S*L*O*W*. I haven't gotten enough feedback to
know whether it would be faster to use a 64-bit system and then enable
swap; obviously the best way would be to use a 64-bit system and then
have gobs and gobs of memory installed on your system. If you have a
32-bit system, and e2fsck needs more than 3-GB of user address space,
you can try using a statically linked e2fsck to try to use the 3GB of
address space most efficiently, but in the long run you will probably
have to use the workaround described in the above link, and resign
yourself to a very long fsck process.

Alternatively, you could try using a backup program which uses a real
database to keep track of reused files, instead of trying to use
directory inodes and hard links as a bad substitute for the same.

- Ted

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 09-22-2008, 04:12 AM
Cameron Simpson
 
Default Rsync --link-dest and ext3: can I increase the number of inodes?

On 21Sep2008 22:27, Theodore Tso <tytso@mit.edu> wrote:
| On Sun, Sep 21, 2008 at 08:44:57PM -0400, Richard Michael wrote:
| > (I run rsync --link-dest backups onto ext3 and am anticipating running
| > out of inodes.) [...]

Hmm. While I take the point that each link tree consumes inodes for the
directories, in a tree that changes little the use of new inodes for
new/changed files should be quite slow.

[...snip e2fsck memory requirements...]
| Alternatively, you could try using a backup program which uses a real
| database to keep track of reused files, instead of trying to use
| directory inodes and hard links as a bad substitute for the same.

But a database is... more complicated and then requires special db-aware
tools for a real recover. The hard link thing is very simple and very
direct. It has its drawbacks (chmod/chown history being the main one
that comes to my mind) but for many scenarios it works quite well.

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?

Cheers,
--
Cameron Simpson <cs@zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

Peeve: Going to our favorite breakfast place, only to find that they were
hit by a car...AND WE MISSED IT.
- Don Baldwin, <donb@netcom.com>

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 09-22-2008, 01:51 PM
Theodore Tso
 
Default Rsync --link-dest and ext3: can I increase the number of inodes?

On Mon, Sep 22, 2008 at 02:12:57PM +1000, Cameron Simpson wrote:
> On 21Sep2008 22:27, Theodore Tso <tytso@mit.edu> wrote:
> | On Sun, Sep 21, 2008 at 08:44:57PM -0400, Richard Michael wrote:
> | > (I run rsync --link-dest backups onto ext3 and am anticipating running
> | > out of inodes.) [...]
>
> Hmm. While I take the point that each link tree consumes inodes for the
> directories, in a tree that changes little the use of new inodes for
> new/changed files should be quite slow.

There are two problems. The first is that the number of inodes you
can consume with directories will go increase with each incremental
backup. If you don't eventually delete some of your older backups,
then you will eventually run out of inodes. There's no getting around
that.

The second problem is that each inode which has multiple inode takes
up a small amount of memory per inode. If you are backing up a very
large number of files, this number may consume more address space than
you have on a 32-bit system. I have a workaround that uses tdb, but
it is quite slow. (I have another idea that might be faster, but I'll
have to try it too see how well or poorly it works.)

> But a database is... more complicated and then requires special db-aware
> tools for a real recover. The hard link thing is very simple and very
> direct. It has its drawbacks (chmod/chown history being the main one
> that comes to my mind) but for many scenarios it works quite well.

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.

> 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? 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?

- Ted

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 09-23-2008, 12:00 AM
Cameron Simpson
 
Default Rsync --link-dest and ext3: can I increase the number of inodes?

On 22Sep2008 09:51, Theodore Tso <tytso@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
inode allocation.

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.

Cheers,
--
Cameron Simpson <cs@zip.com.au> DoD#743

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 

Thread Tools




All times are GMT. The time now is 05:41 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org