On Tue, Aug 24, 2010 at 09:19:31PM +0900, Ryusuke Konishi wrote: > 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. Like Christoph said, inode fundamentally has a sb, so a different data structure would make sense. You really shouldn't be using vfs for sb-less inodes, so therefore you should be able to use your own type for this. But for vfs scale, that doesn't seem to be a problem, the problem for me is just where it duplicates inode init stuff. -- 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
