[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <20080131074916.GN23836@webber.adilger.int>
Date: Thu, 31 Jan 2008 00:49:16 -0700
From: Andreas Dilger <adilger@....com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: linux-ext4@...r.kernel.org, Andreas Gruenbacher <agruen@...e.de>,
bugme-daemon@...zilla.kernel.org, kmshanah@...b.org.au,
"Theodore Ts'o" <tytso@....edu>
Subject: Re: [Bugme-new] [Bug 9855] New: ext3 ACL corruption
On Jan 30, 2008 14:49 -0800, Andrew Morton wrote:
> > Problem Description:
> > On several occasions now I have had e2fsck prune away ACLs on my file systems
> > during a file system check after rebooting a number of (reasonably) long
> > running Samba servers. This morning I decided to manually run fsck before
> > rebooting one of these:
> >
> > # e2fsck -pfv /dev/mapper/vg_main-lv_samba
> > (entry->e_value_offs + entry->e_value_size: 116, offs: 120)
> > /dev/mapper/vg_main-lv_samba: Extended attribute in inode 163841 has a value
> > offset (56) which is invalid
> > CLEARED.
> > (entry->e_value_offs + entry->e_value_size: 116, offs: 120)
> > /dev/mapper/vg_main-lv_samba: Extended attribute in inode 262146 has a value
> > offset (56) which is invalid
> > CLEARED.
While these error messages still exist in e2fsck, this code appears to
have been changed somewhat because these same error messages no longer
get printed in e2fsprogs 1.40.5.
> > Inode size: 256
This is a bit interesting, since it isn't very common to use large inodes.
I suspect this relates to the problem.
> > These are production Samba servers making fairly extensive use of file and
> > directory ACLs. Thus far, I've only noticed the corruptions when it came time
> > to upgrade to a new kernel and reboot (and the boot scripts then run fsck).
> > Note that I've never noticed any issues at runtime because of this - only when
> > I later realised that ACLs had been removed from random files and/or
> > directories.
> >
> > I think I will implement some scripts to unmount and run fsck nightly from
> > cron, so I can at least detect the corruption a little earlier. If there is
> > some more helpful debugging output I can provide, please let me know.
There is just such a script in the thread "forced fsck (again?)". Since you
are using LVs for the filesystem.
If you are able to reproduce this, could you please dump the inode and EA
block before fixing the problem.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists