linux-ext4 - Re: EXT4-fs (dm-1): Couldn't remount RDWR because of unprocessed orphan inode list

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 6 Sep 2011 09:37:46 -0700 (PDT)
From:	Christian Kujau <lists@...dbynature.de>
To:	Eric Sandeen <sandeen@...hat.com>
cc:	linux-ext4@...r.kernel.org
Subject: Re: EXT4-fs (dm-1): Couldn't remount RDWR because of unprocessed
 orphan inode list

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"?

> 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@...hat.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?

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

Thanks for replying,
Christian.
-- 
BOFH excuse #190:

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