Alex Rousskov wrote:
> I think I agree with Duane. Despite its unfortunate name, swapfileno is
> essentially a StoreEntry id. The module that maintains StoreEntries has a
> right to assign its own ids to the objects it maintains. Additional levels
> of indirection do not scare me as they are not likely to add significant
> overhead, especially if StoreEntry ids are guaranteed to be allocated in a
> sequential manner.
I obviously do not agree here.
The key for StoreEntry is cache_key, not swapfileno.
swapfileno is assigned when a object is swapped out to disk, not when a
object is cached in memory (or not cached).
swapfileno is not indexed in any way. There is no way to find the
corresponding StoreEntry from a swapfileno, short of doing a linear
search of all StoreEntries.
So in every aspect, swapfileno is a kind of name/index to the on disk
object, not the StoreEntry. To me it makes no sense that the StoreEntry
manager should care about a information entity entirely used by the
filesystem code and of no use to the StoreEntry manager.
/Henrik
Received on Tue Jul 29 2003 - 13:15:59 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:12:15 MST