From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: Fw: Re: Process hangs copying large file to cifs filesystem Date: Fri, 25 Jun 2004 13:21:58 -0700 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20040625132158.5d859e77.akpm@osdl.org> References: <20040625012931.16e4c7f5.akpm@osdl.org> <20040625145234.GN12308@parcelfarce.linux.theplanet.co.uk> <20040625113214.3324d830.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: viro@parcelfarce.linux.theplanet.co.uk, sfrench@us.ibm.com, linux-fsdevel@vger.kernel.org Return-path: Received: from fw.osdl.org ([65.172.181.6]:19896 "EHLO mail.osdl.org") by vger.kernel.org with ESMTP id S266207AbUFYUTQ (ORCPT ); Fri, 25 Jun 2004 16:19:16 -0400 To: Linus Torvalds In-Reply-To: List-Id: linux-fsdevel.vger.kernel.org Linus Torvalds wrote: > > > > On Fri, 25 Jun 2004, Linus Torvalds wrote: > > > > - ramfs deadlocks on "sync()", since it can't write out inodes > > > > - stale and bad inodes get unhashed, and end up being unwritable. > > > > - totally stale reason that doesn't exist any more. > > There might also be a race on "get rid of inode" from the filesystem > standpoint, and unhashing the inode would be the atomic "now nobody will > call us any more" point. NFS exports etc in particular tend to have all > these interesting things where kNFSd ends up touching inodes even after > they have been unliked, because it uses the magic "look up by inode" > interace. hm, but we've called ->dirty_inode() on it prior to testing the unhashedness. > Although I think the I_CLEARING bits etc should also act as atomic points > of "nobody will touch this any more", but what do I know? That should be so. > Anyway, I do believe that if we remove the check for hashedness, we'd need > to really stress it over a long period in 2.7-like circumstances before we > do it in a "real" kernel. > Yes, this will explode in our faces for sure. I was going to stick a printk in there as a starting point, but ramfs might be a problem. It would, I think, be cleaner to permit ramfs inodes to be dirtied, but refuse to write them out due to memory-backedness. I'll play with it a bit.