From patchwork Thu Oct 25 08:39:57 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Tokarev X-Patchwork-Id: 194073 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id EC7FA2C0094 for ; Thu, 25 Oct 2012 19:40:15 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933325Ab2JYIkN (ORCPT ); Thu, 25 Oct 2012 04:40:13 -0400 Received: from isrv.corpit.ru ([86.62.121.231]:33215 "EHLO isrv.corpit.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933317Ab2JYIkL (ORCPT ); Thu, 25 Oct 2012 04:40:11 -0400 Received: from gandalf.tls.msk.ru (mjt.vpn.tls.msk.ru [192.168.177.99]) by isrv.corpit.ru (Postfix) with ESMTP id 308D9A1C92; Thu, 25 Oct 2012 12:40:10 +0400 (MSK) Received: by gandalf.tls.msk.ru (Postfix, from userid 1000) id 069CF285; Thu, 25 Oct 2012 12:40:08 +0400 (MSK) From: Michael Tokarev To: linux-ext4@vger.kernel.org Cc: sandeen@redhat.com, Michael Tokarev Subject: [PATCH] ext4: do not try to write superblock on journal-less readonly remount Date: Thu, 25 Oct 2012 12:39:57 +0400 Message-Id: <1351154397-14743-1-git-send-email-mjt@msgid.tls.msk.ru> X-Mailer: git-send-email 1.7.10.4 Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org When a journal-less ext4 filesystem is mounted on a read-only block device (blockdev --setro will do), each remount (for other, unrelated, flags, like suid=>nosuid etc) results in a series of scary messages from kernel telling about I/O errors on the device. This is becauese of the following code ext4_remount(): if (sbi->s_journal == NULL) ext4_commit_super(sb, 1); at the end of remount procedure, which forces writing (flushing) of a superblock regardless whenever it is dirty or not, if the filesystem is readonly or not, and whenever the device itself is readonly or not. The proposed fix tests whenever both old mount flags and new mount flags does not include MS_READONLY, and only in this case calls ext4_commit_super(). Maybe it is sufficient to check for MS_READONLY just in old mount options (old_sb_flags). Note this is journal-less mode, so, for example, we weren't have journal replay operation, so if old flags include MS_REASONLY, we shuold have no dirty blocks at all, and there's no reason to call ext4_commit_super(). But only in case both old and new flags include MS_READONLY we're certain we will not write anything - if new flag does not include this bit, we will write sooner or later anyway, so preventing just one commit_super() at the _beginning_ of mount is not really necessary. This change probably applicable to -stable, -- not because it fixes a serious bug, but because the messages printed by the kernel are rather scary for an average user. On the other hand, actual usage of ext4 in nojournal mode on a read-only medium is very rare. Thanks to Eric Sandeen for help in diagnosing this issue. Signed-off-By: Michael Tokarev --- fs/ext4/super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ext4/super.c b/fs/ext4/super.c index 3e0851e..2e896fd 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -4687,7 +4687,7 @@ static int ext4_remount(struct super_block *sb, int *flags, char *data) } ext4_setup_system_zone(sb); - if (sbi->s_journal == NULL) + if (sbi->s_journal == NULL && !(sb->s_flags & old_sb_flags & MS_RDONLY)) ext4_commit_super(sb, 1); unlock_super(sb);