From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: Oops when Deleting Large File Date: Tue, 21 Jan 2003 12:21:42 -0800 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <3E2DABD6.C3FE91C2@digeo.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org Return-path: Received: from digeo-nav01.digeo.com (digeo-nav01.digeo.com [192.168.1.233]) by packet.digeo.com (8.9.3+Sun/8.9.3) with SMTP id MAA07327 for ; Tue, 21 Jan 2003 12:21:43 -0800 (PST) To: "Charles P. Wright" List-Id: linux-fsdevel.vger.kernel.org "Charles P. Wright" wrote: > > When testing a new disk array I created a large (1.4TB) file that filled > up the entire file system (dd ended with ENOSPC). After removing it I got > an Oops, the machine was totally locked, but I reproduced it over a serial > line. Attached is the original Oops and the Oops run through ksymoops > after a reboot. > > This is using a RedHat stock kernel 2.4.18-19.8.0smp on 8.0. The file > system is ext3, and has a total of 1372158232 1k blocks. > > Has anyone else seen this behavior? > Not really. Could be related to this fix (which I forgot to send to Marcelo, oops) Under rare conditions (filesystem corruption, really) it is possible for ext3_dirty_inode() to require _two_ blocks for the transaction: one for the inode and one to update the superblock - to set EXT3_FEATURE_RO_COMPAT_LARGE_FILE. This causes the filesystem to go BUG. So reserve an additional block for that eventuality. fs/ext3/inode.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) --- 25/fs/ext3/inode.c~ext3-transaction-reserved-blocks Sat Dec 14 18:28:21 2002 +++ 25-akpm/fs/ext3/inode.c Sat Dec 14 18:28:21 2002 @@ -2698,7 +2698,7 @@ void ext3_dirty_inode(struct inode *inod handle_t *handle; lock_kernel(); - handle = ext3_journal_start(inode, 1); + handle = ext3_journal_start(inode, 2); if (IS_ERR(handle)) goto out; if (current_handle && _