Re: [RFC] exofs: New truncate sequence

[Nick Piggin <npiggin@suse.de>]

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

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