Re: [RFC] exofs: New truncate sequence

[Boaz Harrosh <bharrosh@panasas.com>]

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.

<snip>

>
>> 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