Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751420AbVKOKla (ORCPT ); Tue, 15 Nov 2005 05:41:30 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751422AbVKOKla (ORCPT ); Tue, 15 Nov 2005 05:41:30 -0500 Received: from cantor2.suse.de ([195.135.220.15]:31374 "EHLO mx2.suse.de") by vger.kernel.org with ESMTP id S1751420AbVKOKla (ORCPT ); Tue, 15 Nov 2005 05:41:30 -0500 From: Neil Brown To: Miklos Szeredi Date: Tue, 15 Nov 2005 21:41:21 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17273.47953.233462.316302@cse.unsw.edu.au> Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, trond.myklebust@fys.uio.no Subject: Re: [PATCH ] Fix some problems with truncate and mtime semantics. In-Reply-To: message from Miklos Szeredi on Tuesday November 15 References: <20051115125657.9403.patches@notabene> <1051115020002.9459@suse.de> X-Mailer: VM 7.19 under Emacs 21.4.1 X-face: v[Gw_3E*Gng}4rRrKRYotwlE?.2|**#s9D > Finally, if vmtruncate succeeds, and ATTR_SIZE is the only change > > requested, we now fall-through and mark_inode_dirty. If a filesystem > > did not have a ->truncate function, then vmtruncate will have changed > > i_size, without marking the inode as 'dirty', and I think this is wrong. > > And if filesystem does not have a ->truncate() function and it caller > was [f]truncate(), ctime and mtime won't be set. > > That's wrong too, isn't it? I don't think that is a problem. The filesystem would have had a ->setattr function which would have been told that the size had changed, and it would have had to change the inode, and so would have updated the ctime and probably mtime. Changing i_size without marking the inode dirty is an issue of consistency of common data structures and inode_setattr should be careful about that. Changing ctime/mtime when the isize changes is an issue of filesystem correctness, and the filesystem callbacks should handle that. Changing mtime when isize DOESN'T change is an issue of obscure POSIX/SUS semantics. It was less clear where this should be handled. I think the handle of this is now better. NeilBrown - 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/