💾 Archived View for kamalatta.ddnss.de › cwfs2.txt captured on 2021-11-30 at 20:18:30.

View Raw

More Information

➡️ Next capture (2024-07-08)

-=-=-=-=-=-=-

Logoaddress
Study of cwfs
table of contents

    1.0.0 What is cwfs
    2.0.0 cwfs console
    2.1.0 Overview
    2.2.0 backup of fsworm
    3.0.0 Structure of fsworm
    3.1.0 Block
    3.2.0 dump stack
    3.3.0 Super Block
    3.4.0 Directory Entry Block
    3.5.0 Indirect Block
    3.6.0 File Block
    3.7.0 Fsworm Root
    3.8.0 Dump order
    3.9.0 qid
    4.0.0 Structure of fscache
    4.1.0 Config Block
    4.2.0 Tcache Block
    4.3.0 Mapping
    4.3.1 bucket
    4.3.2 cache entry
    4.3.3 age
    4.3.4 state
    4.4.0 free block and dirty block
    4.5.0 msize and csize
    4.6.0 Map from Worm to Cache
    4.7.0 msize determination algorithm
    4.8.0 Fscache Root
    5.0.0 Recovery
    5.1.0 recovery
    5.2.0 Review on recovery
    5.3.0 What is lost by Recovery
    6.0.0 Other Configurations
    6.1.0 pseudo-RAID 1
    6.2.0 fake WORM
    6.2.1 Creating fake WORM
    6.3.0 Tvirgo
    7.0.0 Misc.
    7.1.0 What did I do that day?
    7.2.0 atime
    7.2.1 Plan 9
    7.2.2 Linux
    7.2.3 OSX
    8.0.0 cwstudy
    8.1.0 usage
    References 

2012/10/20
2013/03/14 renewal
Updated on March 20, 2013
Updated 2013/04/02
Updated 2013/04/10
2013/04/24 Update

For the summer vacation in 2012, I was trying 9front's cwfs. cwfs consists of fscache and fsworm, but we decided to look it up from fsworm. The reason why you are more interested in fsworm is that information such as file history is placed in fsworm and recovery when fscache crashes is done based on fsworm.
Of course, any device eventually will die. Backup is necessary for fsworm. It may be possible to put cwfs itself in RAID, but it's too overkill for me. Add another HDD and want to have a copy of fsworm there. So, how can we copy it in a short time? I wanted to elucidate this problem.

The cwfs attached to 9front is cwfs64x. Therefore, we will explain it based on cwfs64x.

Note: This article is just my memo so far. Of course, it may contain errors. I would be pleased if you let me know if you find an error.

What is cwfs

This section is incomplete. I will write it in my spare time.

Figure 1. layer

Sean Quinlan (Ph.D)
Ken Thompson (Ken's fs)
Plan 9 2nd edition (1995)
Geoff Collyer (2007/03/27 mail)
9front (2011)
Past History
WORM (write once read many)
It will not disappear (can not be erased)
dump

Comparison with Mac / OSX time machine
pdumpfs

Previously we had one assigned for the server.
memory: Memory in the dedicated file server
disk: disk cache
WORM: Optical disc

Currently it runs under Plan 9 user program cwfs
Advantages of being a user program: It is easy to check the mechanism.
memory: memory in cwfs daemon
disk: fscache partition of file server
WORM: File server fsworm partition

cwfs (or cwfs32)
cwfs64
cwfs64x

cwfs console

Overview

The size of my partition on cwfs is as follows.

  term% ls - l / dev / sdC 0 / fs *
 - rw - r ---- - S 0 arisawa arisawa 22848146432 Sep 13 09: 50 / dev / sdC 0 / fscache
 - rw - r ----- S 0 arisawa arisawa 114240734208 Sep 13 09: 50 / dev / sdC 0 / fsworm
 term%

The cwfs console uses commands

  con -C /srv/cwfs.cmd

You will be able to use with.

Note: Create one new window

  cat /srv/cwfs.cmd

Run it from another window

  echo statw >> /srv/cwfs.cmd

May be executed. Distribution seems to assume this method.

Running statw on the cwfs console will output usage statistics for fsworm. Next, an example of the output is shown.

  > statw
 cwstats main
	 filesys main
		 maddr = 3
		 msize = 10313
		 caddr = 1035
		 csize = 1392255
		 sbaddr = 1755217
		 craddr = 1755389 1755389
		 roaddr = 1755392 1755392
		 fsize = 1755394 1755394 0 + 25%
		 slast = 1754642
		 snext = 1755393
		 wmax = 1755392 0 + 25%
		 wsize = 6972701 1 + 0%
		   8600 none
		 230005 dirty
		      0 dump
		 1153555 read
		     95 write
		      0 dump1
		 cache 17% full
 >

Figure 2. Example of statw output from the cwfs console.
The prompt " > " is not issued in the official distribution version.
I am trying to go out with a modified version by the author.

The numbers on the right of the equal sign ( maddr to wsize ) (the first and second columns) represent the size. The information of the number in the first column is obtained from Tcache block (block address 2) of Tcache . The second column is obtained from fsworm Note 1 . These units are block except for msize . Only msize is a bucket number.

Note 1: This part is incorrect. The second row is also obtained from fscache. The cache of the last super block of fsworm is included in fscache and this is displayed. fsize for fsize , the information in the second column matches the information obtained from the last super block. fsize is the value at the time of executing the statw command, which is consistent with fsize obtained from the Tcache block of Tcache . (2013/04/24)

Notice that fsworm does not include information on fsworm's partition size. It may be replaced by a larger partition when fsworm is full, so in that case it would be designed to just copy the contents of the full partition to the new partition .

Both fscache and fsworm are managed in block units. In the case of cwfs64x, 1 block is 16 KB. Hereinafter, block is represented by an address. ba[0] means the first block, and ba[1] means the second block.

wsize 6972701 /dev/sdC0/fsworm the size of /dev/sdC0/fsworm the number of blocks.

  6972701 * 16 * 1024 == 114240733184

This is 1024 less than the actual size of /dev/sdC0/fsworm , but since it is being used as a unit, an unusable area has occurred.

It should be noted that there is no concept of format in fsworm. Because it is Write Once, after formatting it can not write data! 3

It is written to fsworm in order from the top block. snext (next super block) indicates the next block to be written. When you dump, a block called super block is written first, followed by the body of the data. Super block serves as a boundary for every dump and plays a fundamental role in fsworm.

sbaddr (super block address) is the address of the super block written last. Also, slast is the address of the preceding super block.

Note 2: The block managed by cwfs is different from the block as the unit of reading / writing managed by the driver.
Note 3: WORM in its original meaning will not be used recently. The significance of the existence of an optical disk as a backup medium has disappeared, substituting WORM for a hard task is low cost and easy to use. The following explanation also assumes the use of a hard disk.

Backup of fsworm
Revised 2013/03/06

Although fsworm is very robust (in its mechanism), it still has the risk of data loss due to hardware crashes. To do the backup you have a copy of fsworm (eg fsworm-bak).

For each dump, you might think that you can copy only the newly created block in fsworm, but the story is not that easy. This is because unwritten blocks exist under the last dumped super block. In my observation there are two kinds of them.
(a) reserved blockNote 1
(b) free block
.
(a) is a block of fsworm that is used in fscache, but has not yet completed dump.
(b) is a block of fsworm that fscache can use in the future.

Note 1: "reserved block" is a term that I am using arbitrarily. This term does not exist in the literature.

Structure of fsworm

Block

Both fscache and fsworm are managed in units of block. In the case of cwfs64x, 1 block is 16 KB. Hereinafter, block is represented by an address. ba[0] means the first block and ba[1] means the second block. Together, the first two blocks are special. The address of block is specified by 8 B data. In the program, the data type is indicated by Off .

In the case of fscache, ba[0] contains config information. ba[1] seems not to be used.
In the case of fsworm, there is no indication that the first 2 blocks are used.

Each block has Tag . However, not all the blocks are formatted.

The size of Tag is 12 B in the case of cwfs 64 x, and it is placed at the end of the block. Its structure is as follows.

  struct Tag
 {
	 short pad; / * make tag end at a long boundary * /
	 short tag;
	 Off path;
 };

The value of pad is 0. tag indicates the type of block. path way of thinking about the value of path is different for each tag .

The area excluding Tag 12B is a data area (hereinafter referred to as Data) from 16 KB and has a structure for each type of block. To summarize

  block = Data + Tag

.

Note 1: Recent HD has large capacity. Formatting all the blocks takes a huge amount of time. In addition, the WORM device can not write if formatted!

dump stack
2013/02/28

When dump is repeated, dumped data is stacked on fsworm. Data will never be overwritten. The situation is shown in Fig. 3 (left).

Figure 3. dump

Hereinafter, the block of block address n is represented by ba[n] . ba[0] and ba[1] are not used. When cwfs is executed, first three blocks

  ba [2]: super block
	 ba [3]: cfs root block
	 ba [4]: ​​dump root block

Is made. It does not contain information on files included in fscache.
Note: The words "cfs root block" or "dump root block" do not appear in formal documents or program code. "Cfs root address" and "dump root address" appear.

Blocks are stacked for each dump. We call the block that is stacked with one dump simply as dump. One dump always includes three blocks, "super block", "cfs root block", "dump root block". Figure 3 (right) shows the internal structure of dump.

In the block between super block and cfs root block, the content of fscache is saved (only the difference updated from the previous dump).

The block between the cfs root block and the dump root block contains information on the dumped date. The required number of blocks depends on the number of dumps.

Super Block

The most basic thing to capture the structure of fsworm is super block. The tag of super block is Tsuper (= 1). When we read the code of cwfs, the path the Tag of super block is QPSUPER (= 2).

One super block is created when you dump fscache. First, super block is written to fsworm, then the body of the data is written block by block (right in Figure 3).

The structure of super block

  struct Superb
 {
	 Fbuf fbuf;
	 Super 1;
 };

have.

Fbuf has an array of addresses of free blocks inside. I will postpone commentary on free block.

Super1 is important.

  struct Super 1
 {
	 Off fstart;
	 Off fsize;
	 Off tfree;
	 Off qidgen; / * generator for unique ids * /
	 / *
	  * Stuff for WWC device
	  * /
	 Off cwraddr; / * cfs root addr * /
	 Off roraddr; / * dump root addr * /
	 Off last; / * last super block addr * /
	 Off next; / * next super block addr * /
 };

Figure 4. Structure of Super1

As can be seen, each super block has the address ( next ) of the next super block. And the first super block starts with ba[2] . Therefore, if you follow the super block from ba[2] order, you will know the address to be dumped next. Next, an example of the output result is shown. (This tool will be introduced later)

  super blocks:
 2
 Five
 69908
 85793
 104695
 222009
 ...
 1751346
 1754278
 1754381
 1754569
 1754642
 1755217
 1755393

The last 1755393 is the super block address to be made next. The contents of Super1 ba[1755217] are (for example) as follows.

  super1 fstart: 2
 super1 fsize: 1755394
 super1 tfree: 92
 super1 qidgen: 6d76e
 super1 cwraddr: 1755389
 super1 roraddr: 1755392
 super1 last: 1754642
 super1 next: 1755393

Some of these information is also obtained from the cwfs console.

sbaddr 1755217 : current super block (last written super block)
snext 1755393 : The next dump schedule address (that is, the super block address to be created next)
slast 1754642 : super block address one before the sbaddr

Directory Entry Block
Updated 2013/03/02

Next is the directory entry block. Tag.tag of this block is Tdir . Also, Tag.path matches the Tag.path of the parent directory.

The directory entry block contains one or more of the following directory entries (Dentry) (up to 62 in the case of cwfs64x).

  struct Dentry
 {
	 char name [NAMELEN];
	 Userid uid;
	 Userid gid;
	 ushort mode;
		 #define DALLOC 0x8000
		 #define DDIR 0x4000
		 #define DAPND 0x2000
		 #define DLOCK 0x1000
		 #define DTMP 0x0800
		 #define DREAD 0x4
		 #define DWRITE 0x2
		 #define DEXEC 0x1
	 Userid muid;
	 Qid 9 p 1 qid;
	 Off size;
	 Off dblock [NDBLOCK];
	 Off iblocks [NIBLOCK];
	 long atime;
	 long mtime;
 };

Figure 5. Directory entry

Since the names of files and directories are included here, the size of NAMELEN-1 depends on the allowable name length ( NAMELEN-1 ).

The dump root block is one of directory entry blocks. In the case of my system at home, you can see the dumped date as follows.

  term% ls / n / dump
 / n / dump / 2012/0801
 / n / dump / 2012/0802
 / n / dump / 2012/0804
 / n / dump / 2012/0813
 ....
 / n / dump / 2013/0121
 / n / dump / 2013/0127
 / n / dump / 2013/0128
 / n / dump / 2013/0205
 ....

The first line is generated for the first time on dump (August 1, 2012).

  ls - l / n / dump / 2012/0801

You can access the files on this day as follows.

  maia% ls - l / n / dump / 2012/0801
 d-rwxrwxr-x M 495 sys sys 0 Jul 31 2012 / n / dump / 2012/0801/386
 d-rwxrwxr-x M 495 sys sys 0 Jul 31 2012 / n / dump / 2012/0801/68000
 d-rwxrwxr-x M 495 sys sys 0 Jul 31 2012 / n / dump / 2012/0801/68020
 d-rwxrwxr-x M 495 sys sys 0 Jul 31 2012 / n / dump / 2012/0801 / acme
 d-rwxrwxr-x M 495 adm adm 0 Jul 31 2012 / n / dump / 2012/0801 / adm
 ....
 d-rwxrwxr-x M 495 sys sys 0 Jan 18 2012 / n / dump / 2012/0801 / mnt
 d-rwxrwxr-x M 495 sys sys 0 Jan 18 2012 / n / dump / 2012/0801 / n
 d-rwxrwxr-x M 495 sys sys 0 Jul 31 2012 / n / dump / 2012/0801 / power
 d-rwxrwxr-x M 495 sys sys 0 Jul 31 2012 / n / dump / 2012/0801 / power64
 d-rwxrwxr-x M 495 sys sys 0 Jul 31 2012 / n / dump / 2012/0801 / rc
 d-rwxrwxr-x M 495 sys sys 0 Jul 31 2012 / n / dump / 2012/0801 / sparc
 d-rwxrwxr-x M 495 sys sys 0 Jul 31 2012 / n / dump / 2012/0801 / sparc 64
 d-rwxrwxr-x M 495 sys sys 0 Jul 31 2012 / n / dump / 2012/0801 / sys
 dr-xr-xr-x M 495 sys sys 0 Jan 18 2012 / n / dump / 2012/0801 / tmp
 d-rwxrwxr-x M 495 sys sys 0 Aug 1 2012 / n / dump / 2012/0801 / usr
 maia%

Figure 6. ls / n / dump

The dumped date information ( YYYY/MMDD ) is between dump root address and cfs root address. (Figure 3)

In this case, blocks are connected as shown in the next figure 7.

Figure 7. Connection of directory entry block

A rectangle represents one block. In this figure, none is a directory entry block. Since the number of dumps is still small, the date information of 2013 can be made in time with one directory entry block, but multiple blocks will be required within the time.

In Plan 9, as you can see from the Dentry structure in Figure 5, the name of directory and the information such as mode live in the same block. On UNIX, on the other hand, information such as mode is placed in the inode and is a block different from the list of names (Fig. 8). The origin of this difference seems to be that in UNIX, in order to support hard link, it is necessary to have the link counter in another block (specifically, inode) different from the name.

Figure 8. In the conceptual diagram of unix inode, we write contents as contents of file or other directory.

Qid9p1 's Qid9p1 structure

  struct Qid 9 p 1
 {
	 Off path; / * was long * /
	 ulong version; / * should be Off * /
 };

However, this path is set to 1 in the first bit when mode is a directory (that is, when mode&DDIR != 0 ). (I'm not sure about the reason why I designed this way.) The official qid, ie the command

  ls - ql

The qid displayed is the one with the first bit of this qid.path , that is, qid.path&~DDIR .

In the case of cwfs 64 x, one Dentry is 260 B. Therefore, one block can hold up to 62 Dentry .

name contains the file name and directory name. NAMELEN is 144 in the case of cwfs NAMELEN x. Since the name ends with '\0' , the maximum length of the name is 143 characters. In addition to the name, basic information for directories and files is included in this.

Dentry mode&DDIR == 0 represents a file ( mode&DDIR == 0 ), the block dblock[NDBLOCK] the file contents can be traced based on direct block ( dblock[NDBLOCK] ) and indirect block ( iblocks[NIBLOCK] ). The block containing the file contents is tagged with Tfile .

Dentry mode&DDIR != 0 is a directory ( mode&DDIR != 0 ), the mode&DDIR != 0 in which the directory contents (the information of the files and directories contained therein) is placed is set to direct block ( dblock[NDBLOCK] ) and indirect block ( iblocks[NIBLOCK] ). The block containing the directory contents is tagged with Tdir .

In the case of NDBLOCK the value of NDBLOCK is 6 and the value of NIBLOCK is 4.

Data is directly written to 6 direct blocks. Because 16 * 1024 - 12 B data can be written in one direct block, 6 direct blocks can be written with a total of 6 * (16 * 1024 - 12) B data. In the case of a directory, up to 372 (= 62 * 6) Dentry can be handled.

Indirect Block

For the block indicated by iblocks[0] included in the iblocks[0] structure of the directory entry block,

  (16 * 1024 - 12) / 8 = 2046

Block addresses. Here, 8 is the size of one block address. ) These block addresses indicate the location of the data (ie direct block). Therefore

  2046 * (16 * 1024 - 12) = 33497112 B

Can be written. Let's say that such block information is the primary indirect block.

iblocks[1] , a secondary indirect block is written. In other words, the block addresses are written in this block, but these addresses are the primary indirect block addresses (not the data location). Therefore

  2046 * 2046 * (16 * 1024 - 12) = 68535091152 B

Can be written.

Likewise, iblocks[2] has

  2046 * 2046 * 2046 * (16 * 1024 - 12) = 140222796496992 B

And iblocks[3] has

  2046 * 2046 * 2046 * 2046 * (16 * 1024 - 12) = 286895841632845632 B

.

The tag of indirect block

  iblocks [0] Tind 1
	 iblocks [1] Tind 2
	 iblocks [2] Tind 3
	 iblocks [3] Tind 4

. Also, any of these Tag.paths matches the qid of the parent directory.

File Block

The block containing the contents of the file is tagged with Tfile . Tag.path of this block matches the qid of the directory to which this file belongs.

One file block has a maximum

  16 * 1024 - 12 B

File data can be saved.

The contents of the file are managed in block unit. Will all blocks be rewritten when the contents of the file is updated? According to my experiment, it is not. If you add data to the end of a file larger than one block, only the last block is updated. Other blocks are used as they are. However, this experiment
(a) The append attribute is specified in the file
(b) writing at the end of the file by seeking at the end of the experiment under either condition.

If I open a large file larger than 16 KB with a text editor and add data to the end, I think that it can be completely rewritten. (I have not done an experiment though ...)

Characteristics of cwfs in which only rewritten blocks are newly generated is particularly important in servers. On my server, the log file of web server is 1.7 GB.

  1757143424 Oct 18 17: 13 http

It will not go on to keep copying files of this size every day1.

Note 1: On Mac / OSX's Time Machine or Linux pdumpfs, if the file has been updated, a new copy of it will be made. If we try to realize the function of TimeMachine with only hard links, copy will be inevitable specification. Since the server carries a large log file which is updated day by day, it should not be suitable for server use at all. In the case of database files, even cwfs should be removed from daily dump. It is safer to log transactions.

Fsworm Root
2013/03/09

All information on fsworm can be traced from the dump root block at the top of the dump stack. You can find out this address from roaddr of cwfs console. Figures 6 and 7 are the first part of the path seen from here.

Actually roaddr is a root block managed by fscache, but it matches dump root block of fsworm.

Dump order

The dump is done based on the current fscache. First, super block is written to fsworm. Following this, the information at the end of the directory tree is written in order. Thus, in fsworm, for example

  / 2012/0925 / ....

Is created, the last / before 2012 , before 0925 before that ...

qid

From the user, you can see the qid of the file or directory by adding q option to ls command. For example

  maia% ls - ql
 (000000000009 baa2 6 00) - rw - rw - r - M 326 web web 33597 Mar 8 15: 01 bucket.png
 (000000000009 baa 3 300) - rw - rw - r - M 326 web web 13693 Mar 8 15: 02 bucket.svg
 (0000000000089b8c 2 00) - rw - rw - r - M 326 arisawa web 782 Sep 28 10: 11 console.txt
 (0000000000089b8d 2 00) - rw - rw - r - M 326 arisawa web 2401 Oct 15 21:21 cwfs.svg
 ...
 maia%

As shown in FIG. The part of hexadecimal notation in the head () is qid, and the next digit is qid version.
According to the manual qid is unique within the file system.

If it is unique, the qid must be managed. It seems that qidgen in super block is there for that (Figure 4).

You can tell by experimenting but qid does not change by changing file name. Version changes when content changes.
So, when creating an editor, you can use it to know whether or not you have changed by something else at the time of saving, but time stamp is easier, so I used qid so far There is nothing. (The qid of unix seems to be different)

Except in fsworm and fscache, qid and its version are included in the directory entry (Figure 5), and you can see that the block concerning the contents is the same qid. That is, it seems to be used to confirm the affiliation of block.

Structure of fscache

  ba [0] config
	 ba [1] -
	 ba [2] Tcache

  ba [maddr] map
	 ...
	 ba [caddr] cache
	 ...

Config Block
2013/03/05

As far as cwfs64x is concerned, the following data was written in the text format from the beginning in my config block ( ba[0] ). (This content can also be seen with the printconf command of cwfs console)

  service cwfs
 filsys main c (/ dev / sdC 0 / fscache) (/ dev / sdC 0 / fsworm)
 filsys dump o
 filsys other (/ dev / sdC 0 / other)
 noauth
 newcache
 blocksize 16384
 daddrbits 64
 indirblks 4
 dirblks 6
 namelen 144

noauth means allowing access to cwfs without authentication. noauth should be noted that noauth is a special setting only allowed at the experimental level in a secure environment.
What I use at university is the February version of this year, which is not noauth . (2013/04/10)

In addition, this block is tagged as follows.

  pad: 0000
	 tag: 10 (Tconfig)
	 path: 0

The source code has the following structured data.

  struct Conf
 {
	 ulong nmach; / * processors * /
	 ulong nuid; / * distinct uids * /
	 ulong nserve; / * server processes * /
	 ulong nfile; / * number of fid - system wide * /
	 ulong nwpath; / * number of active paths, derived from nfile * /
	 ulong gidspace; / * space for gid names - derived from nuid * /

	 ulong nlgmsg; / * number of large message buffers * /
	 ulong nsmmsg; / * number of small message buffers * /

	 Off recovcw; / * recover addresses * /
	 Off recovro;
	 Off firstsb;
	 Off recovsb;

	 ulong configfirst; / * configure before starting normal operation * /
	 char * confdev;
	 char * devmap; / * name of config-> file device mapping file * /

	 uchar nodump; / * no periodic dumps * /
	 uchar dumpreread; / * read and compare in dump copy * /
	 uchar newcache;
 };

Data in this is given (in the source code) for each type of cwfs during the initialization process.

Tcache Block

Tcache block manages basic information about cwfs. You can see this in the cwfs console.

  struct Cache
 {
	 Off maddr; / * cache map addr * /
	 Off msize; / * cache map size in buckets * /
	 Off caddr; / * cache addr * /
	 Off csize; / * cache size * /
	 Off fsize; / * current size of worm * /
	 Off wsize; / * max size of the worm * /
	 Off wmax; / * highwater write * /

	 Off sbaddr; / * super block addr * /
	 Off cwraddr; / * cw root addr * /
	 Off roraddr; / * dump root addr * /

	 Timet toytime; / * somewhere convienent * /
	 Timet time;
 };

Each block of fscache is cached in memory. Every ten seconds the cache of memory is written to fscache (if there is an update).

Mapping
Updated 2013/03/08

Each block of fsworm is mapped to the cache block of the cache area of ​​FIG.

Let cba be the cache block address of cba , cba

  caddr <= cba <caddr + csize

. A block of fsworm 0 to wsize is mapped to this area of ​​fscache.

The total number of cache blocks is indicated by csize (in the cwfs console). caddr all remaining caddr starting with caddr are not cache blocks.

In the example of my system, the number of blocks of fsworm is 6972701, whereas the number of cache blocks of fscache is 1392255. Therefore, it has about 1/5 cache capacity. Also, 13604540 blocks can be taken in fscache, but only 1035 + 1392255 (= 1393290) are actually used. The unused area is about 0.1%.

Just thinking about it might think of mapping as shown in Table 1.

Table 1. a simple but problematic mapping from fsworm to cache

Here, cache is written in fscache's cache area. The address shown is counted from caddr .

However, this mapping suffers from problems. If an fsworm block is cached, there may be cases where other fsworm blocks that are mapped to the same cache block can not enter cache.

So cwfs keeps bucket in between, giving flexibility to mapping. The situation is shown in Table 2.

Table 2. real mapping implementation of cwfs.

For ease of explanation, block address of fsworm is set to wa and cache address counted from caddr to ca wa%msize that wa%msize with the same wa%msize is ca%msize to ca of ca%msize . The state of actual mapping is managed by bucket in map block of fscache.

bucket

A block from caddr to caddr in maddr is a map block, and its tag is Tbuck . The map block is a collection of buckets, and the bucket contains the state of cache and the block address of the corresponding fsworm.

Each bucket has the following structure.

  struct Bucket
 {
	 long agegen; / * generator for ages in this bkt * /
	 Centry entry [CEPERBK];
 };

Each map block can hold up to BKPERBLK (= 10) BKPERBLK .

Figure 9. Structure of fscache (cwfs64x)

The total number of msize included in msize is given by msize . In the following, bucket is numbered from 0 to msize - 1 in ascending order of block address, and it is called bucket address.

cache entry

Each bucket has CEPERBK (= 135) Cache Entries. Each Cache Entry represents the state of the current map.

  struct Centry
 {
	 ushort age;
	 short state;
	 Off waddr; / * worm addr * /
 };

In order to find the block address cba of the corresponding fscache from the block address ba cba , first

  bn = ba% msize

. Then check the waddr of 135 cache entries in bucket[bn] . If the block of block address ba of fsworm is cached, there should be some matching ba it. Letting this cache entry be entry[ce]

  cba = msize * ce + bn + caddr

Can be obtained with. Details are explained in "Map from Worm to Cache".

Conversely, to obtain the block address ba of cba from the block address cba fscache currently being cached, first

  bn = (cba - caddr)% msize # bucket addr
	 ce = (cba - caddr) / msize # entry addr

The bucket address bn can be found by looking up the waddr of the cache entry ce in it.

The cache area block of fscache has "state" by cache entry. In the following, let's say that the state of the cache block is ◯◯ or the worm address corresponding to the cache block is ◯◯.

age

age represents the age of the cache block. Small values ​​are old. So it is conceptually close to birth day rather than age. When it becomes necessary to cache newly, the small cache of age is preferentially discarded (when Cnone does not exist). And the value of agegen of bucket becomes the value of age be newly allocated. If data is allocated to cache, agegen increases by 1. The maximum value MAXAGE=10000 age exists. When it exceeds it, reallocation of age is necessary, but details are not understood because I have not read the code well.

state

The cache state is the state of the corresponding Centry and has the following values.

  Cnone = 0
	 Cdirty = 1
	 Cdump = 2
	 Cread = 3
	 Cwrite = 4
	 Cdump 1 = 5

The state of an Cnone cache block is Cnone to Cnone . In my observation, waddr in this case seems to be garbage and has no meaning.

In the case of cache which reads data from worm, waddr is the address itself of the original worm. The state of cache is Cread . In this case the contents of the cache block are the same as the corresponding block of fsworm. (Naturally because it is a cache)

When an existing directory or file is changed, the Cread tag of that cache changes to Cwrite . And waddr is not changed. Of course it will not go overwrite on dump, so at that time it will be saved in the new worm address and waddr in the cache entry should be updated at the same time. If abnormally dumped, the state will be Cread .

When creating a new directory or file, wba corresponding to that cache block is assigned an unused address of worm. The state is Cdirty . When dump is completed it should be Cread .

The cache of the state Cnone and Cread does not need to reflect the change in waddr . Therefore, it means that the block of fscache corresponding to this Centry may be discarded (if necessary).

By the way, when you run the cwfs console statw command

  8600 none
		 230005 dirty
		      0 dump
	        1153555 read
		     95 write
		      0 dump1

We examine Centry directly and display the distribution (number) of values ​​of state .

free block and dirty block
2013/03/11
2013/03/14 revision
2013/03/29 Correction
2013/04/10 added

It is better to classify as follows.
(a) unwritten block
(b) dirty block
(c) free block

The unwritten block in (a) is an unwritten block existing in the dumped area.
The dirty block in (b) is a block which is called Cdirty in fscache. When cwfs creates a new file or directory, it associates worm's address with cache, and Cdirty cache's state to Cdirty . This worm address is an unused address, and if unwritten block is available, use it.
Immediately after dump

  (a) ⊇ (b)

.
(c) free block is a block that is registered as a free block in fscache among dirty blocks. They are not linked to the file tree. Linked dirty blocks are subject to dump, but blocks deviated from link are not dumped. cwfs はこれらをゴミとして捨てるのではなく、新たに dirty block を作る時に利用する。
cwfs は free block の list を持っている。free block list は supper block の中と、fscache のTfreeで tag 付けられた block に存在する。supper block およびTfree block には 2037 個の block address 情報を保持できる。
従って

 (b) ⊇ (c)

.

fscache の Cwrite の状態の block は、実際に dump される時に初めて dump 先の address が確定する。これらの address は最後の dump の上に積み上げられる。他方 Cdirty の状態の block には、取りあえず fsworm の address と関係付けられる。

そもそも free block など発生させないように巧くやれないのか? いろいろ考えるが、結構難しそうである。file や directory の削除が問題である。dump が毎日朝5時に行われるとしよう。昼間の作業でいくつかの directory や file を新たに作ったとする。それらをC1,C2,...,Cnとする。fscache 内のこれらの block はどれもCdirtyの状態に置かれ、fsworm の address と関係付けられる。これらの内のいくつかはその日の内に削除されることもあるだろう。削除されたものをD1,D2,...,Dmとする。 C1,C2,...,CnからD1,D2,...,Dmを差し引いた部分が dump されるのであるが、dump で生成される fsworm の address が連続している事は期待しがたく、「穴」を持つ事となる。それらは free block として将来の利用のために予約されるはずである。

もちろん、削除した file や directory は直ちに親 directory の entry から削除されるが、その contents の状態はCdirtyのままになっている。

Cdirty問題は僕にはまだ分からない事が多い。僕の fscache は大量のCdirty block を抱えている。どうやら、この状態は異常らしい。原因は何か? 考えられるのは cwfs console の clri コマンドで大きな directory を削除したあとに、check free コマンドを行わなかった事。rm コマンドによってファイルを削除した場合には、不要になった block は free block list に入って行くが、clri の場合には入らないらしい。それらは利用されない block として捨てられるらしい。

super block には free block list を持ち、2037 個の free block を登録できる。これを超えた free block の address は、 Tfreeでタグ付けられた fscache の block に記録されている。 Tfree block は super block と同様に free block list を持っている。free block list の構造体は両者とも同じである。

super block やTfree block に含まれる free block をfree[n] ( n=0,1,... ) とする。ソースプログラムを追って行くと、 free[0]は特殊であることが分かる。これはTfree block への pointer なのである。もっと正確に言えば、 free[0]に対応する fscache の address がTfree block になっているはずである。(図10)

図10. freelist chaine

msize と csize

msize個の bucket の中にはmsize*CEPERBK個の cache entry が存在する。筆者のケースでは、 msizeが 10313 なので、この計算結果は 1392255 となる。この数字はcsizeに一致する。 In other words,

 csize = msize*CEPERBK

の関係が成立する。1つの Cache Entry は 1つの cache block を管理しているのである。

msize個の bucket を収納するには、

 (msize+BKPERBLK-1)/BKPERBLK

個の block が必要である。割り算の形が複雑なのは、切り上げているからである。筆者のケースでは、 msizeが 10313 なので、この計算結果は 1032 となる。これにmaddrの 3 を加えて、 caddrの 1035 と一致する。 In other words,

 caddr = (msize+BKPERBLK-1)/BKPERBLK + maddr

の関係が成立する。

Map from Worm to Cache

bnを bucket address、 ceを、その bucket の中の cache entry のアドレスとする。 bnとceは次の範囲にある。

 0 <= bn < msize
	0 <= ce < CEPERBK

bnとceを基に、cache block address を対応させなくてはならない。
2つの自然な考え方がある。
(a) bn*CEPERBK+ce+caddr
(b) msize*ce+bn+caddr
もちろん他のもっと複雑なマッピングは考えられるが、それらを採用する理由は存在しない。
そして、実際には後者の方式(b)が採用されている。

前 者は採用しがたい。なぜなら、ファイルは fsworm の連続した block を占める傾向がある。従って (a) を採用したならば、新たに作成された大きなファイルのキャシュ情報は1つの bucket を占有することになる。するとその bucket が管理する cache block には、(fsworm に dump しない限り)新たにキャッシュできなくなる。

さらに後者の場合には、fsworm の連続した block をキャッシュした場合に、fscache でも連続した block になる可能性が高いところにある。(ハードディスクの seek time が節約できる。)

msize の決定アルゴリズム

msizeはどのような計算で決定されるか?
map block と cache block の合計数をmとすると、
map block をn個にした場合の可能なmn (= csize ) の値は、

 (n-1)*BKPERBLK*CEPERBK < m - n <= n*BKPERBLK*CEPERBK

を満たす必要がある。 In other words,

 1.0*m/(1 + BKPERBLK*CEPERBK) <= n < 1.0*(m + BKPERBLK*CEPERBK)/(1 + BKPERBLK*CEPERBK)

を共に満たす必要があるが、そのようなnは

 n = (m + BKPERBLK*CEPERBK)/(1 + BKPERBLK*CEPERBK)

で得られる。 That is,

 m - n = ((m - 1)*BKPERBLK*CEPERBK)/(1 + BKPERBLK*CEPERBK)

このように計算されたmnはCEPERBKの倍数である保証が無い。従って次の補正を加える必要がある。

 msize = (mn)/CEPERBK
	csize = msize*CEPERBK
	caddr = (msize + BKPERBLK - 1)/BKPERBLK + maddr

で計算される事になろう。

筆者の fscache は

 1394540 block

確保できるので、

 m = 1394540 - 3 = 1394537

.この計算方式によれば

 msize = 10322
	caddr = 1036
	csize = 1393470

となり、 caddr + csizeは 1394506 である。これは fscache の block 数 1394540 よりも小さいので、これで良いはずなのであるが、実際の cwfs の値は違う。実際には、このmsizeをさらに調整し

 msize = maxprime(msize - 5) # Ken's value
	csize = msize*CEPERBK
	caddr = (msize + BKPERBLK - 1)/BKPERBLK + maddr

としている( cw.c )。ここにmaxprime(n)は、 nを超えない最大の素数である。この調整が何故必要なのか? 筆者には不明である。(fsworm と fscache との関係では、この調整は不要なはずである。)

Fscache Root
2013/03/09

fsworm が root を持つように、fscache も root を持っている。(持たなければ directory tree を辿れない)

fscache の root block の address は fsworm の dump stack top の dump root block の address を基にして、通常の mapping rule に従って決定されている。

Recovery

復元 (recovery)
2013/02/28 更新

cwfs に異常をもたらす原因はいろいろあるが、主なケースは次の2つであろう。
(a) 書き込み中の停電
(b) ハードウェアクラッシュこれらはさらに、様々なケースで細分化されるが、ここでは fsworm が健全である(あるいは同じようなことであるが、fsworm のバックアップが存在している)ことを仮定する。この場合には、fsworm に基づいて復元することになる。

以下の仮定を置く:

 /dev/sdC0/fscache
	/dev/sdC0/fsworm

が存在し、

    fswormは健全であり、
    fscacheの先頭 block には正しい config 情報が含まれている。

その元では、cwfs のスタートで(9front では)

 bootargs is (tcp, il, local!device)[local!/dev/sdC0/fscache]

のメッセージがでるので

 local!/dev/sdC0/fscache -c

を input し、その後config:の prompt に対して

 recover main
end

で応えればよい。(復元は非常に早い。(1~2秒?)

fscacheの先頭ブロックは、cwfs の活動中には書き込み対象から外されているので、ハードディスクが物理的損傷を受けていない限り、データのロスは高々、最後の dump 以降に限られると言える。

fscache の復元に必要な全ての情報が fsworm の block address 範囲 0 からsnextまでの中に含まれている。復元に際して、fsworm の全てを調べる必要は無い。最後にダンプした記録から辿る事ができる。この作業は cwfs が自動的に行うはずであるが、参考のために、fsworm の構造をもう少し詳しく解説する。

Plan9(あるいは9front)では、過去のファイルの状態は

 9fs dump

を実行して

 /n/dump

以下に見えるが、ここに見える全ての情報が次のダンプアドレスsnextの1つ前の block アドレス ( = roaddr = snext - 1 ) から簡単に辿って行くことができる。

後に紹介するプログラム cwstudy は、block アドレスを指定して、その内容を表示する。次は cwstudy の実行例である。

 cpu% cwstudy 1755392
/dev/sdC0/fsworm
tag pad: 0000
tag tag: 11 (Tdir)
tag path: 1

name: /
uid: -1
gid: -1
mode: 0140555
muid: 0
qid path: 80000001
qid ver.: 0
size: 0
dblock: 1755391 0 0 0 0 0
iblock: 0 0 0 0
atime: 1343737574 // Tue Jul 31 21:26:14 JST 2012
mtime: 1343737574 // Tue Jul 31 21:26:14 JST 2012

最初に得られる名前は “ / ” である。作成日は、fsworm が作られた 2012年7月31日となっている。 dblock[0]の1755391は、" / " の下の directory entry block のアドレスである。

 cpu% cwstudy 1755391
/dev/sdC0/fsworm
tag pad: 0000
tag tag: 11 (Tdir)
tag path: 1

name: 2012
uid: -1
gid: -1
mode: 0140555
muid: 0
qid path: 80000001
qid ver.: 27
size: 0
dblock: 1755390 0 0 0 0 0
iblock: 0 0 0 0
atime: 1348729247 // Thu Sep 27 16:00:47 JST 2012
mtime: 1343797238 // Wed Aug 1 14:00:38 JST 2012

block アドレス1755391に含まれるディレクトリの名前は2012である。1つしか現れていないのは、fsworm の運用開始が2012だからである。

block アドレス1755390には多数の directory entry が含まれている。

 term% cwstudy 1755390
[中略]
name: 0925
uid: -1
gid: -1
mode: 0140555
muid: 0
qid path: 80000001
qid ver.: 27
size: 0
dblock: 1755212 0 0 0 0 0
iblock: 0 0 0 0
atime: 1348584237 // Tue Sep 25 23:43:57 JST 2012
mtime: 1348584237 // Tue Sep 25 23:43:57 JST 2012

name: 0927
uid: -1
gid: -1
mode: 0140555
muid: 0
qid path: 80000001
qid ver.: 27
size: 0
dblock: 1755388 0 0 0 0 0
iblock: 0 0 0 0
atime: 1348729247 // Thu Sep 27 16:00:47 JST 2012
mtime: 1348729247 // Thu Sep 27 16:00:47 JST 2012

それらの名前は、ダンプした月日を表している。また、それらは

 ls /n/dump/2012

で表示される名前と一致する。

さらに進んで、 2012の下にある0927の directory entry も同様に見つける事ができる。それらの名前は

 ls /n/dump/2012/0927

で表示される名前と一致する。そこにはadmやsysやusrなどの名前が見えるだろう。

0925のdblock[0]は1755212である。この block アドレスは 9月25日にダンプした block の中に含まれている。(この日には1754642から1755216までが消費された)

9月27日のダンプでは、この日のファイルを全て新たにコピーするのではなく、変更されていないコンテンツに関しては、古いコンテンツをそのまま使う。ここでは0925に関しては、9月25日のコンテンツがそのまま使われている。

fsworm では block 単位の差分法が使われているのである。(この件に関しては後にまた吟味する)

復元(recovery)について吟味

fsworm が健全であれば、super block をsnextまで辿れば、 snextを基に復元できる。では確実にsnextまで辿れるのか?

fsworm が本当の WORM あるいは新品のハードディスクであれば問題はないであろう。 snextの先に、 Tagらしきデータは無いのであるから間違う余地は無い。しかし使い古しのハードディスクであればどうだろう?
Tagを頼りに super block を辿る際に、ゴミをTagと勘違いするかもしれない。super block のTag構造体は

 struct Tag
 {
	short pad; /* make tag end at a long boundary */
	short tag;
	Off path;
};

であり、 padは 0、 tagは 1、 pathは 2 である。ゴミの中で、この 12Bが完全に一致する確率は 2 -96で注1 、十分に小さいと考えるかもしれない。何しろ、fscache がクラッシュする確率自体、極めて小さくて、サーバのライフタイム(5年程度か?)の中に、あるか無いかだ。

し かし、こうした確率の計算は、ランダムなデータが書き込まれている事を前提にしている。この使い古しのハードディスクの fscache パーティションが、以前に fscache パーティションとして利用されていたものを、そのまま使ったらどうだろう? 誤認される確率は fsworm の中での super block の割合までに上がるので、無視できないかもしれない。従って、fscache のパーティションを作る場合に注意した方が良いだろう。(パーティションの先頭アドレスを少しずらすとか...)

fscache の Tcache block の中には fsworm の最後の super block との整合性を確認できる情報が含まれている。従って通常の recovery においてはこのような心配はいらないはずである。

注1: 実際には、 tagとpathだけで辿っているので、確率は 2 -80である。この確率を小さくするためには、他にslastの情報を使う手もあろうが、そこまでの価値があるかは怪しい。

Recovery によって失われるもの
2013/03/28

free block で失われるものがある。 free block とは既に dump された領域に存在する、まだ書き込まれていない block である。cwfs は、ここに data を書き込む機会があれば書き込もうとする。記憶スペースを有効に使おうとしているのである。free block のうち 2037 個は superblock が管理しており、この情報は fsworm にあるので失われない。しかし 2037 個を超えた部分の free block list は fscache の Tfree block に存在している。Tfree block は fsworm にコピーされない。これらは Recovery で失われる。

Other Configurations
2013/04/02

pseudo-RAID1

結局現在の cwfs configuration

 filsys main c(/dev/sdC0/fscache)(/dev/sdC0/fsworm)

の下では fsworm の backup を取るのは至難の技であると諦めて、他の configuration

 filsys main c(/dev/sdC0/fscache){(/dev/sdC0/fsworm)(/dev/sdD0/fsworm)}

を採用することとした。
これは pseudo-RAID1 の configuration である。デバイスまるごとではなく、fsworm partition だけを RAID1 風に処理してくれる。
/dev/sdC0/fswormと/dev/sdD0/fswormはサイズが異なっても構わない。その場合には小さい方に合わせられる。
書き込みの順序は、(この場合には) D0 → C0であり、読み取りはC0で行われる。

ディスク編成の変更にあたっては、準備が必要である。

    コピーを取らなくてはならない。partition まるごとは時間がかかりすぎるので、最後の super block までのコピーに制限する必要がある。
    それでもまだ時間が掛かりすぎるかも知れないので、その間の auto dump を止める必要がある。そのためには、cwfs にパッチをあてないといけない。

もっとも、RAID は僕が家庭で使うには大げさなのであるが...

家で使っている限り順調に動いている。大学のサーバーもこれでやることにした。

fake WORM

Cinap によると fake WORM の中には written block の bit map があるそうである。この場合、HDD を WORM の代わりに使うのだから、現在の利用状態を示す bit map を持つ事は可能なのである。この場合の configuration は

 filsys main c(/dev/sdC0/fscache)f(/dev/sdC0/fsworm)

.

これを使えば、普段は 1 個の disk を使い、気の向いた時に backup disk を追加してバックアップを取る僕のような気まぐれな人間に適した処理が可能であろうと思える。

fake WORM の作成

僕 の WORM は通常の WORM なので、fake WORM を作る場合には、device のコピーという訳には行かないはずてある。新たに構成する事とし、安全のために、PXE で立ち上げた端末で作業することとした。local disk には、これから cached fake WORM を構成する plan9 partition を準備しておく。

 /dev/sdC0/fscache
	/dev/sdC0/fsworm

この下で

 cwfs64x -c -f /dev/sdC0/fscache

を実行する注1 。

注1: cwfs のコマンドの使い方は、Bell-labs 版(Geoff のオリジナル版)と 9front 版では異なる。ここでは 9front 版に基づく。9front 版では、kfs や fossil など、他のファイルシステムと -f オプションの使い方の統一を計っている。

9front 版では-c option で config mode に入る。 configの prompt に対して次のデータを input する。

 service cwfs
filsys main c(/dev/sdC0/fscache)f(/dev/sdC0/fsworm)
filsys dump o
filsys other (/dev/sdC0/other)
ream other
ream main
end

以上は一回限りである。

次に cwfs console へのコマンドと shell レベルのコマンドが発生する。ここでは cwfs console へのコマンドをfscons>で表す。

以下の操作は新しい window の中で行うのが無難である。

 fscons> users default
fscons> newuser arisawa
fscons> allow

term% mount -c /srv/cwfs /n/cwfs
term% mkdir /n/cwfs/adm
term% cp /adm/users /n/cwfs/adm

fscons> users

注意: newuser arisawaは、筆者のシステムの system owner はglendaではなくarisawaだから必要になったのであり、 glendaのままであれば不要である。

このあとは、筆者のcpdirを使うのが早い。

 cpdir -mvug /root /n/cwfs adm 386 acme cfg cron lib mail rc sys

/rootの下にあるfd 、 mnt 、 n 、 tmp 、 usrは個別に確認した方が無難である。
特に、 /root/n/の下にはcwfsが見えているはずである。

Tvirgo

fakeworm の場合には cwfs console の statw で���示されるwsizeから、 Tvirgo block が始まる。 Tvirgo block は fsworm の block 0 からwsizeま での使用状況を bitmap で表している。書き込まれた block には bit 1 が立てられ、まだ書き込まれていない block の bit は 0 である。fsworm の先頭 2 block は書き込まれていないので、bitmap の最初の 2 bit は 0 である。

fakeworm は fsworm の末尾に bitmap が入り込むので、その分、 wsizeは小さくなる。

Misc.

What did I do that day?
2013/03/18

「あの日は何をしていたのだろう?」と僕が考える場合には、ファイルの修正などの話であり、飲みに行ったとかの話ではない。
あの日に変更されたファイルを全て列挙するには、UNIX では find コマンドを使うと思う。膨大なファイルの中から、変更されたファイルを探し出す作業は(ファイルの量にもよるが)多くの時間を要し数秒では終わらない。ちなみに僕の MacBook では僕の$HOMEの探索だけでも30秒程要している。(結構たくさんのファイルを持っているせいもある)

 bash$ touch a.txt
bash$ time find $HOME -newer a.txt -print
find: /Users/arisawa/.emacs.d/auto-save-list: Permission denied
/Users/arisawa/Library/Application Support/Google/Chrome/Default/Cookies
 ...
 ...
find: /Users/arisawa/src/rminnich-vx32-17a064eed9c2/src/9vx/osx/9vx.app: Permission denied

real 0m28.372s
user 0m0.783s
sys 0m18.783s
bash$

ここで紹介するのは僕の作った lr コマンドであり、find の -newer オプションに相当するオプションが存在する。これを使って昨日に変更されたファイルをサーバーの全てのファイルの中から見つけるには次のようにする。

 term% cpu -h ar
ar% 9fs dump
mounting as arisawa
mounting as arisawa
ar% ls /n/dump/2013|tail -2
/n/dump/2013/0317
/n/dump/2013/0318
ar% mtime /n/dump/2013/0317
 1363498134 /n/dump/2013/0317
ar% time lr -lt 1363498134 /n/dump/2013/0318
 ...
 ...
--rw-rw-rw- web arisawa 5819730 2013/03/18 12:54:03 /n/dump/2013/0318/usr/cpa/www/log/dict
d-rwxrwxrwx arisawa arisawa 0 2013/03/17 21:51:56 /n/dump/2013/0318/usr/cpa/www/users
 ...
 ...
0.01u 0.18s 1.91r lr -lt 1363498134 /n/dump/2013/0318
ar%

この日には33個のファイルの変更があった。多くは log ファイルである。変更されたファイルの中には web の cgi に拠るものもある。システムの全てのファイルを探しているのだが2秒弱で探索が完了している。僕は膨大なファイルをサーバー上に持っているにも係わらずで ある!

なぜこんなに高速に変更を調べられるのか?

探索にatimeが利用されているからである。 atimeとは access time の意味である。マニュアルを見てもそれ以上に詳しい説明はない。(Plan9 のマニュアルには read time と書いてあるが、write に対してもatimeが更新される)

注: lr は

 http://plan9.aichi-u.ac.jp/netlib/cmd/lr/

に置かれている。

atime
2013/06/06

実際の動作を見ていると、Plan9 と UNIX(MacOSX や Linux) で振る舞いが異なる。

Plan9 の場合には、ファイルサーバがファイルを探し出すために辿ったルートに存在する全てのディレクトリのatimeが更新されている。膨大な directory tree の中で、指定された日に実際にファイルサーバが辿った道は極く極く僅かである。従ってatimeを見ていれば、必要な探索のルートを大幅に減らす事が可能である。

UNIX では違う。ファイルサーバがファイルを探し出すために辿ったルートに存在するディレクトリのatimeは更新されていない。変更が実際に発生したディレクトリやファイルのatimeだけが更新されている。従って、 atimeを頼りに、更新を効率的に探し出す事はできない。

以下に、Plan9 と UNIX の atime の違いを具体例で示す。

Plan9

 # Plan9
term% date; touch $home/doc/x;ls -dlu /usr $home/doc
Wed Jun 5 07:58:17 JST 2013
d-rwxrwxr-x M 20 sys sys 0 Jun 5 07:58 /usr
d-rwxrwxr-x M 20 arisawa arisawa 0 Jun 5 07:58 /usr/arisawa/doc
 term%

Linux

 # UNIX (Linux)
hebe$ date; touch $HOME/doc/x; ls -dlu /home $HOME/doc
Wed Jun 5 07:56:41 JST 2013
drwxr-xr-x 3 root root 4096 Jun 4 09:49 /home
drwxr-xr-x 9 arisawa arisawa 4096 Jun 5 07:46 /home/arisawa/doc
hebe$

OSX

 # UNIX (OSX)
-bash$ date; touch $HOME/doc/x; ls -dlu /Users $HOME/doc
Wed Jun 5 08:08:27 JST 2013
drwxr-xr-x 6 root admin 204 May 31 07:51 /Users
drwxr-xr-x 3 arisawa staff 102 Jun 5 08:03 /Users/arisawa/doc
-bash$

cwstudy

This section is incomplete.

usage

cwstudy block_address

cwstudy -C block_address

cwstudy path

cwstudy super

文献

[1] Sean Quinlan “A Cached WORM File System”
Softw., Pract. Exper., vol. 21 (1991), pp. 1289-1299
http://plan9.bell-labs.com/who/seanq/cw.pdf

[2] Ken Thompson, Geoff Collyer “The 64-bit Standalone Plan 9 File Server”
http://plan9.bell-labs.com/sys/doc/fs/fs.pdf