From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Piggin Subject: Re: [RFC] exofs: New truncate sequence Date: Tue, 1 Jun 2010 01:09:57 +1000 Message-ID: <20100531150957.GM9453@laptop> References: <4C03ABCA.4050602@panasas.com> <20100531134453.GI9453@laptop> <4C03C40E.2090800@panasas.com> <20100531143337.GK9453@laptop> <4C03CC99.7030404@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]:48605 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754925Ab0EaPKD (ORCPT ); Mon, 31 May 2010 11:10:03 -0400 Content-Disposition: inline In-Reply-To: <4C03CC99.7030404@panasas.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, May 31, 2010 at 05:50:01PM +0300, Boaz Harrosh wrote: > On 05/31/2010 05:33 PM, Nick Piggin wrote: > > On Mon, May 31, 2010 at 05:13:34PM +0300, Boaz Harrosh wrote: > >> On 05/31/2010 04:44 PM, Nick Piggin wrote: > >>> On Mon, May 31, 2010 at 03:30:02PM +0300, Boaz Harrosh wrote: > >>>> --- > >>>> fs/exofs/exofs.h | 1 - > >>>> fs/exofs/file.c | 1 - > >>>> fs/exofs/inode.c | 115 +++++++++++++++++++++++++++--------------------------- > >>> > >>> Can you rip out all the rest of the buffer_head stuff too? > >>> > >> > >> I hope I don't have any left, that was the last, have I missed > >> something? > > > > exofs_invalidatepage, exofs_releasepage, includes of buffer_head.h. > > No point to any of that if you never actually map the buffers or > > use them for tracking state yourself. > > > > Rrr thanks. Yes I'll leave the WARN_ON and do nothing, and remove the > include. I'll submit for linux-next. OK. I'd get rid of it completely before it hits mainline. > Thanks. > > > > > > >> You see this is where exofs is different a file is an object_no on > >> multiple OSD devices. The inode is kept as an attribute of the > >> object. (data as object's data) so a exofs_sbi_remove will just > >> obliterate any association to the object. It was historically > >> called because exofs_truncate used to do what truncate_inode_pages > >> does today. (And some other in memory book keeping.) But with > >> your help all this was cleaned up. > > > > OK, I was thinking the underlying object itself needs to be trimmed > > to match i_size similarly to just a block based filesystem? Like > > exofs_oi_truncate appears to. > > > > Yes you are right, generally, but since I'm doing exofs_sbi_remove() > just after that then there is no point. the osd_remove will take care of > that anyway. I fugured it would, just wanted to check. > >> Do you see any operation I missed that might need cleaning from the > >> generic VFS inode, that might now leak. As far as storage is concerned > >> I'm covered. > >> > >> [I ran git clone linux; rm -rf linux; 100 times in a loop and the OSD > >> storage stayed constant size. So I presume there is no storage leak. > >> OSD is good in this respect] > > > > I can't see anything off hand. Was just flagging points where > > vmtruncate or truncate had been called and is not now. If you > > have all those covered, then you should be OK. > > > > > > I'll be testing this particular branch for a while. I have a chicken > and egg problem. I think I'm kind of dependent on Al's vfs for-next > branch. Do you think the patch could also work with Linus-2.6.35-rc1? > I'm afraid that even if so It might conflict with Al's tree if I put > it independently in the osd/for-next tree. I would keep them based on top of Christoph's patches (just cherry pick the exofs hunks in the meantime).