doc/caching-in-blocks

   1 Caching in blocks
   2 =================
   3
   4 $Id$
   5
   6 Why blockcache
   7
   8   - There is just one reson that one should have blockcache.
   9     You want to edit filer larger then you blockcache. Example below
  10     is with a cache-size of 100M.
  11
  12      : lha@nutcracker ; less kdc.3log
  13      kdc.3log: No space left on device
  14      : lha@nutcracker ; ls -l 'kdc.3log'
  15      -rw-r--r--  1 314  daemon  179922925 Sep 18 00:05 kdc.3log
  16
  17
  18    - Speed is not really an issue since most files are accessed for
  19      head of the file to tail of the file. Then you can use
  20      incremental opening of the file. This would be less gross change.
  21
  22 Prior work
  23    adaptive buffercache, usenix99
  24      - this will apply to both reading and writing
  25
  26 Double buffering problem
  27 ========================
  28
  29 One way that might work is that files that are accessed read-only are
  30 done on the underlaying file (and in that vnode's page-cache).
  31
  32 But as files that are write-ed too are dubblebuffered. If the file has
  33 been accessed before the node's and the underlaying node's all pages
  34 are flushed to make sure we are double buffering.
  35
  36 Incremental open
  37 ================
  38
  39 This still doesn't solve the problem with large files, it only solve
  40 the problem that its takes long time to read the first few bytes of a
  41 large file.
  42
  43 * Opening a file
  44
  45  wait until there is a token that you want or wakeup returns an error
  46
  47  >open
  48  <installdata, installs token and fhandle
  49  <wakeup open
  50
  51  failure case
  52
  53  >open
  54  <wakeup with errno
  55
  56 * Reading data (read and getpage)
  57  check for readable data for this user
  58 retry:
  59  check if existing offset is more then wanted offset,
  60    do the read from the cache file, return
  61  check if wanted-offset over end of file, fail
  62  >getdata(wanted-offset)
  63  <installattr(filesize,existing-offset)
  64  goto retry
  65
  66 * Writing data (write and putpage)
  67
  68  XXX rewrite this with respect to
  69
  70  check for writeable data for this user
  71 retry:
  72  check if existing offset is more then writing offset,
  73    do the write to the cache file, return
  74  check if beginning-offset over end of file, fail
  75  >getdata(beginning-offset)
  76  <installattr(filesize,beginning-offset)
  77  goto retry
  78
  79 * When closing
  80
  81  if data dirty, write back to the fileserver.
  82
  83 Caching in blocks
  84 =================
  85
  86 Writing
  87   - what triggers a write
  88       + shortage of blocks
  89         interesting case, necessary to detect random writing ?
  90       + fsync/close
  91         just flush all dirty blocks, or sync whole file
  92         just flush what blocks are dirty to userlevel
  93         one rpc-call with bitmask ?
  94   - how to cluster writing (how to detect)
  95       + with shortage of block in the hard one
  96
  97 Reading
  98   - how to read-ahead (how far, how to detect)
  99       + prior work
 100
 101 What to cache (in general terms)
 102 =============
 103
 104   - how long time does it take to open a fhandle_t (fhtovp) ?
 105       benchmark ? (fhopen() abort 5 times faster then open())
 106   - how many no vnode can the layer hold up (related to above)
 107