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