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