On Tue, 24 Aug 2010 17:48:44 +1000, Nick Piggin <npiggin@xxxxxxxxx> wrote: > On Sun, Aug 22, 2010 at 07:05:00PM +0900, Ryusuke Konishi wrote: > > This is a patchset to remove own inode hash table from nilfs. > > > > The current version of nilfs uses inode not only to manage regular > > files, directories, symlinks but also for some types of metadata and > > for caching file blocks relocated by GC. > > > > The last type of inodes is called gc-inodes, and nilfs keeps them with > > an own hash table. > > > > With this patchset, the gc-inodes will be stored in vfs inode cache > > like regular inodes, and the own inode hash is deleted. > > > > I hope this would be helpful for the vfs scalability work. > > This looks like a reasonable direction to me, and you would get > more of the benefits of the inode cache scalability work, but this > wasn't the biggest prolem for my series, because I'm not going digging > into the filesystems themselves. > > The reason I broke nilfs2 is because it duplicates a lot of the > generic inode initialisation code. This really should go in core > code because nilfs2 does not own the generic inode fields. Yes, that is what I want to do next. I really want to eliminate the duplication. > It just needs some helper function to do the non-sb related init > stuff for you. I'm seeking the way to make that special type of inodes hold a valid sb. If it's not feasible, I think nilfs should not borrow inode object and should define just enough structure instead. Ryusuke Konishi -- 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
