From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Stephen Elliott" Subject: RE: EXT4 Strange FSCK Behavior Date: Fri, 3 May 2013 11:56:27 +0100 Message-ID: <001001ce47ec$dc994810$95cbd830$@ntlworld.com> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Return-path: Received: from mail-we0-f181.google.com ([74.125.82.181]:42874 "EHLO mail-we0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1763077Ab3ECK4V (ORCPT ); Fri, 3 May 2013 06:56:21 -0400 Received: by mail-we0-f181.google.com with SMTP id x8so1182639wey.12 for ; Fri, 03 May 2013 03:56:20 -0700 (PDT) Received: from STEVEHP (know-mailgateway-4.server.virginmedia.net. [62.254.26.109]) by mx.google.com with ESMTPSA id k5sm16261132wiy.5.2013.05.03.03.56.19 for (version=TLSv1.1 cipher=RC4-SHA bits=128/128); Fri, 03 May 2013 03:56:19 -0700 (PDT) References: In-Reply-To: Content-Language: en-gb Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Any feedback folks??? -----Original Message----- From: Stephen Elliott [mailto:techweb@ntlworld.com] Sent: 29 April 2013 01:45 To: linux-ext4@vger.kernel.org; 'linux-fsdevel@vger.kernel.org' Subject: EXT4 Strange FSCK Behavior Hi all, I thought I'd reach out to your guys as trawling various forums and docs has not really got me any further. It may also be a possible bug. 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 but to say they are shared with 0 files makes no sense! And... Surely this should be corrected by FSCK? Smart logs are all good.... It was one of the first things I checked. Thanks...