All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Andreas Dilger <adilger@sun.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-ext4@vger.kernel.org, Andreas Gruenbacher <agruen@suse.de>,
	bugme-daemon@bugzilla.kernel.org, kmshanah@ucwb.org.au,
	"Theodore Ts'o" <tytso@mit.edu>
Subject: Re: [Bugme-new] [Bug 9855] New: ext3 ACL corruption
Date: Thu, 31 Jan 2008 08:58:09 -0600	[thread overview]
Message-ID: <47A1E201.7070801@redhat.com> (raw)
In-Reply-To: <20080131074916.GN23836@webber.adilger.int>

Andreas Dilger wrote:
> On Jan 30, 2008  14:49 -0800, Andrew Morton wrote:
>>> Problem Description:

>>> 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.

I think it is somewhat common on samba servers, though.

And it's the new default in the latest e2fsprogs... maybe something will
shake out in the F9 development cycle.

>>> 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.

Which is on the ext3-users list btw...

> If you are able to reproduce this, could you please dump the inode and EA
> block before fixing the problem.

Do you need instructions on doing that?

-Eric

      reply	other threads:[~2008-01-31 14:58 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-9855-10286@http.bugzilla.kernel.org/>
2008-01-30 22:49 ` [Bugme-new] [Bug 9855] New: ext3 ACL corruption Andrew Morton
2008-01-31  7:49   ` Andreas Dilger
2008-01-31 14:58     ` Eric Sandeen [this message]

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=47A1E201.7070801@redhat.com \
    --to=sandeen@redhat.com \
    --cc=adilger@sun.com \
    --cc=agruen@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=bugme-daemon@bugzilla.kernel.org \
    --cc=kmshanah@ucwb.org.au \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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.