Dear Holger, > f...@igh.de wrote on 2018-03-08 16:59:37 +0100 [Re: [BackupPC-users] Serious > error: last backup ... directory doesn't exist!!! - reason found]: > > [...] > > Meanwhile I found the reason: the partition ran out of inodes. As you > > wrote under "How much disk space do I need?" one has to have "plenty > > of inodes". But what does that mean? > > as has been said, that depends directly on what you are backing up.
yes of course, but there are other signicant influences. I have counted the number of inodes in the cpool and in the pc directories. The latter was about 100 times higher. Obviously the number of kept backups is a factor to consider. It seems, the number n_i of inodes required is about n_i = n_f (2 n_b + 1), where n_b: number of backups kept n_f: number of files to backup could anyone confirm or disconfirm this? > > May I ask the following: > > > > - in the "General Server Information" you give some statistical > > information about disk usage; would it be a good idea also to give > > information about inode consumption? > > You mean 'df -i'? yes exactly! I have created a post backup notification e-mail which now contains also the output of "df -i". BTW.: such a post backup notification I would recommend as default. It is not a good idea to conclude a successful backup from a missing message... > > - is it possible and would it make sense to separate the "pc" and the > > "pool/cpool" directories into different partitions? I just did an > > rsync of a BackupPC-directory and found that the files on "pc" are > > mostly empty or small. The file sizes in "pool/cpool" are remarkable > > bigger - I assume these are the "real" files. So one could create > > one partition for "pool/cpool" having about e.g. 64kB per inode and > > another partition having a block size of 1 kB and also 1 kB per > > inode. Maybe this would reduce disk space consumption and also allow > > rsyncing somewhat faster. > > My first thought is to avoid the issue altogether by using a file system > that doesn't statically allocate inodes (e.g. XFS or reiserfs, the latter > I wouldn't recommend for other reasons, though; I don't know about ext4, > btrfs and ZFS, but my guess would be that ext4 has static allocation and > the others dynamic). Why worry about a problem modern file systems simply > don't have? I have made several tests with different file systems (xfs, reiserfs, jfs). After some time of operation I had different kinds of trouble with all of them; especially xfs seems to be sensitive against power blackout (I know UPS could help, but this increases the effort of battery life cycle management; sometimes I found UPS caused more trouble than solved). I consider ext[3/4] the far most robust file system. So if I know how to calculate the required number of inodes it will stay my favorite. Best regards Torsten -- ------------------------------------------------------------------------ Torsten Finke f...@igh.de Ingenieurgemeinschaft IgH Gesellschaft für Ingenieurleistungen mbH Heinz-Bäcker-Str. 34 D-45356 Essen ------------------------------------------------------------------------ ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
