>>>>> On Sat, 22 Dec 2007 08:29:54 -0500 (EST), Steve Thompson said: > > Here's something interesting. Bacula 2.2.4 on both client (64-bit CentOS > 4.5) and director (32-bit CentOS 4.5). > > During a backup: > > JobId 3516 Job asimov_data7.2007-12-20_23.00.08 is running. > Backup Job started: 20-Dec-07 23:44 > Files=111,850 Bytes=1,863,801,574 Bytes/sec=15,977 Errors=0 > Files Examined=16,999,856 > Processing file: /mnt/mda/data7/XXX > SDReadSeqNo=5 fd=14 > > The "Files Examined" count will eventually go to about 18.5 million by the > end of the backup (for every full or incremental backup). However, the > include list for this job includes only a single relatively static file > system, on which there are only just over 13 million inodes in use: > > Filesystem Inodes IUsed IFree IUse% Mounted on > /dev/sdh1 36552704 13377854 23174850 37% /mnt/mda/data7 > > So what is the "Files Examined" count really telling me? The JobFiles > count from a 'list job' is correct, however.
Do you have lots of hard links in that filesystem? Bacula will count those as files but df will not show them. > Secondly, note the very low bytes/sec figure for this backup. This is an > ext3 file system with dir_index turned off: an incremental backup takes > 25-30 hours to complete. I have an identical copy of this file system on > the same client with dir_index turned on: an incremental backup of this > takes only 4 hours. Both are SAS 300GB 10k rpm, RAID-1. Lots of > directories over 4K, I suspect, but I don't know the count. A Bacula backup has to stat every file in the filesystem, so dir_index could make quite a difference. __Martin ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
