|
From: Mimi Z. <zo...@li...> - 2017-07-17 17:04:15
|
On Mon, 2017-07-17 at 14:35 +0000, Magalhaes, Guilherme (Brazil R&DCL) wrote: > Mimi, > Let me update you on the ideas below. > First, on the 2-lookups solution, we have one radix tree inside > another. On the first radix tree, the index is namespace id, which > seems ok (not sparse). The second radix tree is indexed by iint > address, which must be replaced by a rbtree as you indicated. > The second point is about the possible alternative solution I > mentioned. Actually, I realized that we would have possible memory > leaks on that solution since it would not be possible to delete the > namespaced flags when a namespace is released. It would wait when > the namespace is reused for the same iint and then it would finally > reset the flags under that namespace. Then, the namespaced flags > would never be deleted (to avoid the need for locking the inode when > the namespace is released). > > Therefore, we still have 2 options: > 1) namespaced flags tree inside the iint structure, single lookup, > but when namespace is released it would have to lock and unlock each > related inode accessed under that namespace to safely delete the > namespaced flag. There can be hundred/thousands of iints namespaced > flags to delete. Definitely not a good idea. > 2) namespaced flags tree outside the iint structure, we would need 2 > lookups when a namespace flag is referenced. There needs to be two look ups, just not two tree look ups. Mimi |