From: Zheng Liu <gnehzuil.liu@gmail.com>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Stephen Elliott <techweb@ntlworld.com>,
David Jeffery <djeffery@redhat.com>,
"linux-ext4@vger.kernel.org List" <linux-ext4@vger.kernel.org>,
Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>,
Eric Whitney <enwlinux@gmail.com>
Subject: Re: Query FSCK Errors on ext4
Date: Mon, 28 Oct 2013 14:39:06 +0800 [thread overview]
Message-ID: <20131028063905.GA9017@gmail.com> (raw)
In-Reply-To: <F81EF3B4-CEBF-43FD-BD38-0AFFF56014C6@dilger.ca>
[Cc Eric Whitney to confirm this problem]
Hi Andreas,
If I remember correctly, this patch might can fix this problem [1].
1. http://www.spinics.net/lists/linux-ext4/msg39485.html
Regards,
- Zheng
On Mon, Oct 28, 2013 at 12:13:26AM -0600, Andreas Dilger wrote:
> The error reported here is a relatively new one. It only appeared in
> e2fsck 1.42.8, and wasn’t in the code that I’m using locally (1.42.7)
> so I wasn’t sure what it actually meant without looking at it.
>
> It looks like some kind of overflow of the extent tree, which causes
> e2fsck to chop off the last 5 disk blocks (40 sectors), though I’m not
> sure exactly why. From your comments, this can be reproduced with
> your database usage? Does it use fallocate() or any other strange
> IO operations that might be causing this?
>
> Have you tried updating your kernel? If there is repeated corruption
> appearing in the filesystem, then it is either a bug in the kernel or
> in e2fsck. Not really sure which one to blame at this point.
>
> Cheers, Andreas
>
> On Oct 18, 2013, at 9:45 AM, Stephen Elliott <techweb@ntlworld.com> wrote:
>
> > Any feedback on this guys??? Would really appreciate somebody taking a look over this.
> >
> > From: Stephen Elliott [mailto:techweb@ntlworld.com]
> > Sent: 22 September 2013 20:13
> > To: linux-ext4@vger.kernel.org; linux-fsdevel@vger.kernel.org; Andreas Dilger (adilger@dilger.ca); 'Bernd Schubert'
> > Subject: Query FSCK Errors on ext4
> >
> > Hi all,
> >
> > I have theorised that the problem comes from the MS access DB being open (over Samba) on client workstations when the server is reloaded.
> >
> > Since ensuring these are closed prior to reloading, I have not seen further FSCK errors on reload. Is there an explanation for this? I can see why this may corrupt DB but not the filesystem.
> >
> > Just as a primer, I used a ReadyNAS NV+ for many years which was running ext3 and never had this issue. However, since using ext4 on a ReadyNAS Pro, I now see this issue.
> >
> > Many Thanks
> > Stephen Elliott
> >
> > From: Stephen Elliott [mailto:techweb@ntlworld.com]
> > Sent: 23 July 2013 22:02
> > To: linux-ext4@vger.kernel.org; linux-fsdevel@vger.kernel.org; Andreas Dilger (adilger@dilger.ca); 'Bernd Schubert'
> > Subject: RE: FSCK Errors on ext4
> >
> > If it helps guys, the same file as before is causing the issue with inode 4195610, a very large MS access DB.
> >
> > From: Stephen Elliott [mailto:techweb@ntlworld.com]
> > Sent: 23 July 2013 21:52
> > To: linux-ext4@vger.kernel.org; linux-fsdevel@vger.kernel.org; Andreas Dilger (adilger@dilger.ca); 'Bernd Schubert'
> > Subject: FSCK Errors on ext4
> >
> > Hi Andreas / Bernd / all,
> >
> > You may recall advising me on another batch of FSCK errors a few months back.
> >
> > The same device on an ext4 file system has produced the following errors after a clean reload. It seems to be fine now but wanted your input on this. No bad blocks are reported on the devices etc.
> >
> > ***** File system check forced at Tue Jul 23 21:02:13 WEST 2013 ***** fsck 1.42.8 (20-Jun-2013) e2fsck 1.42.8 (20-Jun-2013) Pass 1: Checking inodes, blocks, and sizes Inode 4195619, end of extent exceeds allowed value
> > (logical block 64907, physical block 11435403, len 16) Clear? yes
> >
> > Inode 4195619, i_blocks is 1337216, should be 1337176. Fix? yes
> >
> > Pass 2: Checking directory structure
> > Pass 3: Checking directory connectivity
> > Pass 4: Checking reference counts
> > Pass 5: Checking group summary information Block bitmap differences: -(11435403--11435407) Fix? yes
> >
> > Free blocks count wrong for group #348 (2130, counted=2135).
> > Fix? yes
> >
> > Free blocks count wrong (417470107, counted=417470112).
> > Fix? yes
> >
> >
> > /dev/c/c: ***** FILE SYSTEM WAS MODIFIED *****
> > /dev/c/c: 625785/30212096 files (13.6% non-contiguous), 65923424/483393536 blocks
> >
> > Many Thanks
> > Stephen Elliott
>
>
> Cheers, Andreas
>
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2013-10-28 6:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <008701cecc19$14734370$3d59ca50$@ntlworld.com>
2013-10-28 6:13 ` Query FSCK Errors on ext4 Andreas Dilger
2013-10-28 6:39 ` Zheng Liu [this message]
2013-10-28 9:00 ` Stephen Elliott
2013-10-28 20:53 ` Andreas Dilger
2013-10-28 21:18 ` Stephen Elliott
2013-11-19 12:44 ` Stephen Elliott
2013-11-19 16:46 ` Andreas Dilger
2013-11-19 17:35 ` Stephen Elliott
2013-11-19 20:27 ` Andreas Dilger
2013-11-19 20:48 ` Stephen Elliott
[not found] ` <C8263588-E5AD-4C23-81E3-5852DE3B1FC5@dilger.ca>
[not found] ` <002e01cee56f$46f8e3d0$d4eaab70$@ntlworld.com>
2013-11-20 12:35 ` Bernd Schubert
2013-11-20 12:46 ` Stephen Elliott
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131028063905.GA9017@gmail.com \
--to=gnehzuil.liu@gmail.com \
--cc=adilger@dilger.ca \
--cc=bernd.schubert@itwm.fraunhofer.de \
--cc=djeffery@redhat.com \
--cc=enwlinux@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=techweb@ntlworld.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.