Hi all, Lately I encountered some vague corruptions on my filesystem which were probably caused several weeks ago. My setup is quite extraordinary (using ATA over Ethernet, RAID5, LVM, LUKS), a simple undetected network failure did most probably cause these corruptions. After I recovered the filesystem I decided to set up a weekly cron job to perform an automatic e2fsck on a snapshot. This way, no inconsistencies go undetected for longer than a week and problems can be fixed before additional corruption occurs. However, there is a slight problem with scripting e2fsck: it seems that e2fsck /always/ exits with exit code 1 just because of the fact that the snapshot journal has been replayed. Because of this, the script cannot tell whether there is a real problem or not and keeps e-mailing me. This is a typical output of such an e2fsck run: > # e2fsck.static -f -y -v /dev/loop1 > e2fsck 1.40.8 (13-Mar-2008) > /dev/loop1: recovering journal > Pass 1: Checking inodes, blocks, and sizes > Pass 2: Checking directory structure > Pass 3: Checking directory connectivity > Pass 4: Checking reference counts > Pass 5: Checking group summary information > > /dev/loop1: ***** FILE SYSTEM WAS MODIFIED ***** > > 12609263 inodes used (4.58%) > 258729 non-contiguous inodes (2.1%) > # of inodes with ind/dind/tind blocks: 1174647/20098/15 > 485401393 blocks used (88.17%) > 0 bad blocks > 108 large files > > 8730706 regular files > 3867308 directories > 0 character device files > 3 block device files > 12 fifos > 95342096 links > 11090 symbolic links (9640 fast symbolic links) > 135 sockets > -------- > 107951350 files As you can see: no additional errors. Does anyone have any ideas on how to work around this? Cheers, Bas -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
