All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Christian Kujau <lists@nerdbynature.de>
Cc: linux-ext4@vger.kernel.org
Subject: Re: EXT4-fs (dm-1): Couldn't remount RDWR because of unprocessed orphan inode list
Date: Tue, 06 Sep 2011 11:44:45 -0500	[thread overview]
Message-ID: <4E664DFD.80308@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.01.1109060923340.9183@trent.utfs.org>

On 9/6/11 11:37 AM, Christian Kujau wrote:
> On Tue, 6 Sep 2011 at 11:17, Eric Sandeen wrote:
>> It's probably not a bug or flaw; orphan inodes can occur for legitimate
>> reasons (fs goes down while someone is holding open an unlinked file),
> 
> The filesystem is being constantly accessed by an application, holding at 
> least one file open (readonly). And then there is this mechanism trying to 
> remount the filesystem rw and then ro again every day. I guess this equals
> the scenario of "fs goes down (remount!) while someone is holding open a 
> file"?

well, no - "goes down" means "crashed or lost power"

>> Did you happen to also get a message like this on the original mount?
>>                 ext4_msg(sb, KERN_ERR, "write access "
>>                         "unavailable, skipping orphan cleanup");
> 
> I think I've seen this message before, but I'm nore sure where and it's 
> not in the logs of this particular system.
> 
>> See also commit: 
>>
>> commit ead6596b9e776ac32d82f7d1931d7638e6d4a7bd
>> Author: Eric Sandeen <sandeen@redhat.com>
>> Date:   Sat Feb 10 01:46:08 2007 -0800
>>
>>     [PATCH] ext4: refuse ro to rw remount of fs with orphan inodes
> 
> Yes, I've seen this commit when I was searching where this message came
> from. And I think I understand now why this is happening, but 
> still...if I may ask: can't this be handled more elegantly? Do other 
> filesystems have the same problem?

well, as the commit said, it'd be nice to handle it in remount, yes... :(

> Right now the procedure is to pause the application, stop the nfs exports,
> unmount, fsck, mount, start nfs exports and resume the application. And
> every few days/weeks this has to be repeated, "just because" these daily
> remounts occur (which are the main reason for this, I suppose).

well, seems like you need to get to the root cause of the unprocessed
orphan inodes.

I don't yet have my post-vacation thinking cap back on... does cycling
rw/ro/rw/ro with open & unlinked files cause an orphan inode situation?

-Eric

> Thanks for replying,
> Christian.


  reply	other threads:[~2011-09-06 17:29 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-02 21:00 EXT4-fs (dm-1): Couldn't remount RDWR because of unprocessed orphan inode list Christian Kujau
2011-09-06 16:17 ` Eric Sandeen
2011-09-06 16:37   ` Christian Kujau
2011-09-06 16:44     ` Eric Sandeen [this message]
2011-09-06 18:14       ` Christian Kujau
2011-09-08 18:51       ` Jan Kara
2011-09-10  1:11         ` Christian Kujau
2011-09-10 20:04           ` Jan Kara
2011-09-13  4:52             ` Christian Kujau
2011-09-16  3:49               ` Christian Kujau
2011-09-16 12:04                 ` Amir Goldstein
2011-09-16 12:17                   ` Christian Kujau
2011-09-16 12:36                     ` Amir Goldstein
2011-10-05 18:03                 ` Jan Kara
2011-10-06  1:34                   ` Christian Kujau
2011-10-06 10:12                     ` Toshiyuki Okajima
2011-10-11  8:45                       ` Miklos Szeredi

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=4E664DFD.80308@redhat.com \
    --to=sandeen@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=lists@nerdbynature.de \
    /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.