From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boaz Harrosh Subject: Re: [PATCH 0/6] first step toward the new truncate sequence Date: Mon, 31 May 2010 13:17:35 +0300 Message-ID: <4C038CBF.7050902@panasas.com> References: <20100530204932.GA21002@lst.de> <4C038648.4030304@panasas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: viro@zeniv.linux.org.uk, npiggin@suse.de, jack@suse.cz, linux-fsdevel@vger.kernel.org To: Christoph Hellwig Return-path: Received: from daytona.panasas.com ([67.152.220.89]:32275 "EHLO daytona.int.panasas.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751823Ab0EaKRi (ORCPT ); Mon, 31 May 2010 06:17:38 -0400 In-Reply-To: <4C038648.4030304@panasas.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 05/31/2010 12:50 PM, Boaz Harrosh wrote: > On 05/30/2010 11:49 PM, Christoph Hellwig wrote: >> This series is something that I see as the first major step towards >> a broad switch to the new truncate sequence. The patches get rid >> of the _newtrunc variant of blockdev_direct_IO & friends and >> *_write_begin, and clean up some bits in that area that make the >> switch easier. After this we have all vmtruncate instances except >> for inode_setattr in filesystem code. A second series to deal >> with ->setattr will follow and after that we can easily switch >> over one filesystem after another. >> >> I think this is still 2.6.34 material as it will make the fs >> switches a lot easier and avoid introducing the _newtrunc variants >> for one kernel release. >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > Christoph, Nick hi. > > I'm attempting a truncate conversion for exofs, will need a review. > > I'm basing the first attempt on Al's next tree that has Nicks last > patches. Will rebase on these when they get into that tree. Please > advise on the best tree to use? > (BTW did you mean 2.6.35 above, I guess) > > So one minor thing ext2_setsize can be static: > (It used to be used by the struct inode_operations) > One more thing. ext2_setsize is only used by ext2_setattr do we still need this code? (form ext2_setsize) half of it is done in ext2_setattr already) inode->i_mtime = inode->i_ctime = CURRENT_TIME_SEC; if (inode_needs_sync(inode)) { sync_mapping_buffers(inode->i_mapping); ext2_sync_inode (inode); } else { mark_inode_dirty(inode); } And generic_setattr does some more of that, No? Boaz