From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boaz Harrosh Subject: Re: [RFC] exofs: New truncate sequence Date: Mon, 31 May 2010 17:50:01 +0300 Message-ID: <4C03CC99.7030404@panasas.com> References: <4C03ABCA.4050602@panasas.com> <20100531134453.GI9453@laptop> <4C03C40E.2090800@panasas.com> <20100531143337.GK9453@laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Christoph Hellwig , linux-fsdevel , open-osd To: Nick Piggin Return-path: Received: from daytona.panasas.com ([67.152.220.89]:33889 "EHLO daytona.int.panasas.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755356Ab0EaOuE (ORCPT ); Mon, 31 May 2010 10:50:04 -0400 In-Reply-To: <20100531143337.GK9453@laptop> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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. 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. > >> 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'll see what comes up Boaz