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). -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
