Alex Rousskov wrote:
> Since your definition of swapfileno contradicts with Duane's definition,
> and both definitions are implicit and vague, we can argue forever without
> any progress. A very specific name, "swapfileno" that apparently no longer
> means "swap file number" does not help either.
It does mean "cache_dir number and internal swap file name". It is the
"name/index" sent to the filesystem code when opening/closing objects.
For UFS it is a 1-1 map to swap file number.
> If we can move swapfileno field to the file system specific part of
> StoreEntry without modifying anything in the store manager (fs-independent
> code), Henrik wins.
Basically it is a change in how store_swapout interfaces to the FS
dependent code, and a move of some of the currently fs-independent code
down to the fs-dependent code.
> If we cannot, then Duane is right in keeping that field
> in StoreEntry.
The field belongs in StoreEntry, the decision on what the value should
be belongs in the filesystem code, much like inode numbers belongs in a
directory entry but is assigned independently by lower level code.
The reason why I proposed a delayed assignment model is because for some
store layouts it may not be possible to determine the on disk index key
until some or all of the data has been written.
/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