Thanks Andreas. Unfortunately I was unable to gather this. Even your speculation would be appreciated :) I am watching this box like a hawk now. Will perform weekly scans for a while. -----Original Message----- From: Andreas Dilger [mailto:adilger@xxxxxxxxx] Sent: 08 May 2013 17:22 To: <techweb@xxxxxxxxxxxx> Cc: <linux-fsdevel@xxxxxxxxxxxxxxx> Subject: Re: 2nd Attempt - FSCK Errors On 2013-05-08, at 9:20, "Stephen Elliott" <techweb@xxxxxxxxxxxx> wrote: > Well... I have some new and interesting information. > > After deleting the file, and re-creating from backup, the file system got mounted read only and the following errors were logged: > > May 8 14:58:15 despair kernel: EXT4-fs error (device dm-0): mb_free_blocks:1411: group 5124block 167904376:freeing already freed block (bit 1144) May 8 14:58:15 despair kernel: Aborting journal on device dm-0-8. > May 8 14:58:15 despair kernel: EXT4-fs (dm-0): Remounting filesystem > read-only May 8 14:58:15 despair kernel: EXT4-fs error (device dm-0): > mb_free_blocks:1411: group 5124block 167904377:freeing already freed > block (bit 1145) These errors are consistent with duplicate blocks being inside the same file. It deleted the first set of blocks properly, then when it got to the duplicate referenced ones it spit the errors about the bits already being freed. > Volume seems clean now after reboot and keeps coming back clean. Right, since the corruption was only in that one file. > Any ideas based on this? Did you ever run the "debugfs -c -R 'stat <4195619> ' /dev/c/c" command? (Sorry, I don't recall, lots of other things on the go.) That would at least allow us to see how the corruption was present in the file and create a test case. Without that, we can only speculate on what was wrong, and we might not be able to find the problem. Cheers, Andreas > From: Stephen Elliott [mailto:techweb@xxxxxxxxxxxx] > Sent: 26 April 2013 22:37 > To: 'linux-ext4@xxxxxxxxxxxxxxx' > Subject: FSCK Errors > > Hi all, > > Just rebooted my box today after 200 days uptime and thought I'd request a volume scan and it found errors! I've never had a power outage etc so am keen to know what could have caused this file system corruption? Anyu ideas??? > > I'm running 4.2.21 on a ReadyNAS Pro6, but ultimately it is a Linux (Debian) 2.6.37.6. based system underneath. > > ***** File system check forced at Fri Apr 26 20:08:38 WEST 2013 ***** > fsck 1.41.14 (22-Dec-2010) e2fsck 1.42.3 (14-May-2012) Pass 1: > Checking inodes, blocks, and sizes Inode 4195619, i_blocks is 3135728, > should be 3135904. Fix? yes > > > Running additional passes to resolve blocks claimed by more than one inode... > Pass 1B: Rescanning for multiply-claimed blocks Multiply-claimed > block(s) in inode 4195619: 167904376 167904377 167904378 167904379 > 167904380 167904381 167904382 167904383 167904384 167904385 167904386 > 167949296 167949297 167949298 167949299 167949300 167949301 167949302 > 167949303 167949304 167949305 167949306 Pass 1C: Scanning directories > for inodes with multiply-claimed blocks Pass 1D: Reconciling > multiply-claimed blocks (There are 1 inodes containing > multiply-claimed blocks.) > > File /PREMIER/Premier Automation Purchase OrdersApp V18.5.mdb (inode #4195619, mod time Fri Apr 26 20:07:42 2013) has 22 multiply-claimed block(s), shared with 0 file(s): > Multiply-claimed blocks already reassigned or cloned. > > Pass 2: Checking directory structure > Pass 3: Checking directory connectivity Pass 4: Checking reference > counts Pass 5: Checking group summary information > > /dev/c/c: ***** FILE SYSTEM WAS MODIFIED ***** > /dev/c/c: 615898/30212096 files (13.6% non-contiguous), > 62353456/483393536 blocks > > I'm curious to know what this is all about, shared with 0 files!!!!: > > File /PREMIER/Premier Automation Purchase OrdersApp V18.5.mdb (inode #4195619, mod time Fri Apr 26 20:07:42 2013) has 22 multiply-claimed block(s), shared with 0 file(s): > Multiply-claimed blocks already reassigned or cloned. > > > Every follow on boot with FSCK yields the following: > > > ***** File system check forced at Fri Apr 26 20:21:42 WEST 2013 ***** > fsck 1.41.14 (22-Dec-2010) e2fsck 1.42.3 (14-May-2012) Pass 1: > Checking inodes, blocks, and sizes > > Running additional passes to resolve blocks claimed by more than one inode... > Pass 1B: Rescanning for multiply-claimed blocks Multiply-claimed > block(s) in inode 4195619: 167904376 167904377 167904378 167904379 > 167904380 167904381 167904382 167904383 167904384 167904385 167904386 > 167949296 167949297 167949298 167949299 167949300 167949301 167949302 > 167949303 167949304 167949305 167949306 Pass 1C: Scanning directories > for inodes with multiply-claimed blocks Pass 1D: Reconciling > multiply-claimed blocks (There are 1 inodes containing > multiply-claimed blocks.) > > File /PREMIER/Premier Automation Purchase OrdersApp V18.5.mdb (inode > #4195619, mod time Fri Apr 26 20:07:42 2013) has 22 multiply-claimed block(s), shared with 0 file(s): > Multiply-claimed blocks already reassigned or cloned. > > Pass 2: Checking directory structure > Pass 3: Checking directory connectivity Pass 4: Checking reference > counts Pass 5: Checking group summary information > /dev/c/c: 615898/30212096 files (13.6% non-contiguous), > 62353456/483393536 blocks > > Still same thing with multiply claimed blocks :)? > > Any ideas? > > Many Thanks > Stephen Elliott > > -- > To unsubscribe from this list: send the line "unsubscribe > linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
