On Wed, Jun 11, 2008 at 01:48:35AM +0200, Santi Saez wrote: > Theodore Tso escribió: >> hmm..... can you send me the output of dumpe2fs /dev/sdXX? You can >> run that command while e2fsck is running, since it's read-only. I'm >> curious exactly how big the filesystem is, and how many directories >> are in the first part of the filesystem. >> > Upsss... dumpe2fs takes about 3 minutes to complete and generates about > 133MB output file: True, but it compresses well. :-) And the aside from the first part of the dumpe2fs, the part that I was most interested could have been summarized by simply doing a "grep directories dumpe2fs.out". But simply looking at your dumpe2fs, and take an average from the first 6 block groups which you included in the pastebin, I can extrapolate and guess that you have about 63 million directories, out of approximately 114 million total inodes (so about 51 million regular files, nearly all of which have hard link counts > 1). Unfortunately, BackupPC blows out of the water all of our memory reduction hueristics. I estimate you need something like 2.6GB to 3GB of memory just for these data structures alone. (Not to mention 94 MB for each inode bitmap, and 188 MB for each block bitmap.) The good news is that 4GB of memory should do you --- just. (I'd probably put in a bit more physical memory just to be on the safe side, or enable swap before running e2fsck). The bad news is you really, REALLY need a 64-bit kernel on your system. Because /var/cache/e2fsck is on the same disk spindle as the filesystem you are checking, you're probably getting killed on seeks. Moving /var/cache/e2fsck to another disk partition will help (or better yet, battery backed memory device), but the best thing you can do is get a 64-bit kernel and not need to use the auxiliary storage in the first place. As far as what to advice to give you, why are you running e2fsck? Was this an advisory thing caused by the mount count and/or length of time between filesystem checks? Or do you have real reason to believe the filesystem may be corrupt? - Ted _______________________________________________ Ext3-users mailing list Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
