Ext3 users - Sep 2008 - Rsync --link-dest and ext3: can I increase the number of inodes?

Hello list,

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

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

Thanks,
Richard

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