Hello, On Wed, May 23, 2012 at 01:34:03AM -0400, Kent Overstreet wrote: > On Tue, May 22, 2012 at 10:20:54PM -0700, Tejun Heo wrote: > > Hmmm... I would prefer it to be defined explicitly as union. It's > > rather easy to define it incorrectly (ie. using struct bkey) and then > > pass it around expecting it to have the pad. > > Thing is, things don't expect the pad - bkeys are normally just in a big > chunk of memory concatenated together, and the same functions have to > work both with those and with bare bkeys the code occasionally > manipulates. Hmmm... so it's actually just padding? Padding for what? I thought it was there to provide space for ptr[], no? > > I'm a bit confused. Cache device or cached device? Isn't the key > > dev:offset:size of the cached device? > > No - bkey->key is the offset on the cached device, PTR_OFFSET is on the > cache. > > Confusing, I know. Any ideas for better terminology? Double confused by the "no" and the following sentence seemingly agreeing with what I wrote. So, bkey->key indexes the backend device - the slow big disk and the associated PTRs point into the fast SSD caching device, right? If so, I think 'key' is fine, that's the only thing which can be key anyway. As for PTR_XXX, maybe something which can signify they're the cache would be nicer but with proper comments I don't think it's big deal. Thanks. -- tejun -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
