Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756375Ab2JZGMS (ORCPT ); Fri, 26 Oct 2012 02:12:18 -0400 Received: from li9-11.members.linode.com ([67.18.176.11]:57711 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754930Ab2JZGMQ (ORCPT ); Fri, 26 Oct 2012 02:12:16 -0400 Date: Fri, 26 Oct 2012 02:12:06 -0400 From: "Theodore Ts'o" To: Naoya Horiguchi Cc: Andi Kleen , Tony Luck , Wu Fengguang , Andrew Morton , Jan Kara , "Jun'ichi Nomura" , Akira Fujita , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-ext4@vger.kernel.org Subject: Re: [PATCH 2/3] ext4: introduce ext4_error_remove_page Message-ID: <20121026061206.GA31139@thunk.org> Mail-Followup-To: Theodore Ts'o , Naoya Horiguchi , Andi Kleen , Tony Luck , Wu Fengguang , Andrew Morton , Jan Kara , Jun'ichi Nomura , Akira Fujita , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-ext4@vger.kernel.org References: <1351177969-893-1-git-send-email-n-horiguchi@ah.jp.nec.com> <1351177969-893-3-git-send-email-n-horiguchi@ah.jp.nec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1351177969-893-3-git-send-email-n-horiguchi@ah.jp.nec.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2330 Lines: 48 On Thu, Oct 25, 2012 at 11:12:48AM -0400, Naoya Horiguchi wrote: > + /* Lost data. Handle as critical fs error. */ > + bh = head = page_buffers(page); > + do { > + if (buffer_dirty(bh) && !buffer_delay(bh)) { > + block = bh->b_blocknr; > + EXT4_ERROR_INODE_BLOCK(inode, block, > + "Removing dirty pagecache page"); > + } else > + EXT4_ERROR_INODE(inode, > + "Removing dirty pagecache page"); One of the side effects of calling EXT4_ERROR_INODE (or ext3_error in your ext3 patch), it sets the "file system is corrupt" bit which forces the file system to be fsck'ed at the next boot. If this is just a memory error, it's not clear that this is the right thing to have happen. It's also not clear what the benefit would be is of forcing a reboot in the errors=panic case. If the file system is corrupt, forcing a panic and reboot is useful because it allows a file system to get checked instead of allowing the system to continue on and perhaps cause more data loss. But if what happened is that there was a hard ECC error on a page, we've already lost data. Forcing a reboot isn't going to make things better; and if you force an e2fsck, it will just increase the system's downtime. It's also not entirely clear that throwing away the page is the right thing to do, either, by the way. If you have a hard ECC error, then there has might be a two or three bits that have gotten flipped on that page. But by throwing the dirty page entirely, we're throwing away 4k worth of data. If we go back to first principles, what do we want to do? We want the system administrator to know that a file might be potentially corrupted. And perhaps, if a program tries to read from that file, it should get an error. If we have a program that has that file mmap'ed at the time of the error, perhaps we should kill the program with some kind of signal. But to force a reboot of the entire system? Or to remounte the file system read-only? That seems to be completely disproportionate for what might be 2 or 3 bits getting flipped in a page cache for a file. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/