From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Piggin Subject: Re: [PATCH ver3] exofs: New truncate sequence Date: Wed, 2 Jun 2010 01:09:18 +1000 Message-ID: <20100601150918.GY9453@laptop> References: <4C03ABCA.4050602@panasas.com> <4C04EF92.6060600@panasas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Christoph Hellwig , linux-fsdevel , open-osd To: Boaz Harrosh Return-path: Received: from cantor.suse.de ([195.135.220.2]:59013 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753078Ab0FAPJX (ORCPT ); Tue, 1 Jun 2010 11:09:23 -0400 Content-Disposition: inline In-Reply-To: <4C04EF92.6060600@panasas.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, Jun 01, 2010 at 02:31:30PM +0300, Boaz Harrosh wrote: > > These changes are crafted based on the similar > conversion done to ext2 by Nick Piggin. > > * Remove the deprecated ->truncate vector. Let exofs_setattr > take care of on-disk size updates. > * Call truncate_pagecache on the unused pages if > write_begin/end fails. > * Cleanup exofs_delete_inode that did stupid inode > writes and updates on an inode that will be > removed. > * And finally get rid of exofs_get_block. We never > had any blocks it was all for calling nobh_truncate_page. > nobh_truncate_page is not actually needed in exofs since > the last page is complete and gone, just like all the other > pages. There is no partial blocks in exofs. > [OK do I need a partial read here upto i_size ???] You shouldn't need to. We do have some interesting code trying to deal with mmap data past i_size in core/buffer code. I hope Jan's patches can improve that. But anyway if you are not doing byte based IO, you have to remember that if you mark a page uptodate, it should not contain uninitialized data past i_size. Also, in the writeback path, junk data can get written past i_size too. The latter case is difficult to avoid (due to concurrent mmap writes). It is not technically a leak perhaps, but it's a bit nasty if you allow data to be hidden past i_size. The best course of action IMO is to zero this out at read-in and truncate-extend time. Doesn't seem like you have to worry about any of that if you have byte granularity , although you do have EXOFS_BLKSHIFT defined?