Comments on research!rsc: Absolute File System Design

ken thompson's file server for Plan 9 tags each bl...

2008-04-30T18:25:00.000-04:00

ken thompson's file server for Plan 9 tags each block with a little data (type and path) which isn't quite enough to allow recovering whole files automatically but does allow simple consistency checks that (for me) not only detected problems (hardware and software) but prevented them escalating to destroy file systems (eg, data, directory, and free list blocks have different types).

@marius: Sure, if you used only the linked list to...

2008-03-15T11:10:00.000-04:00

@marius: Sure, if you used only the linked list to navigate, then the file system accesses would be slow. But there's nothing stopping you from building block trees like Unix file systems and using them as hints to find the blocks faster.

The space overhead is pretty minimal: a few words per 4096-byte block would be under 1%. Make the block size bigger and the overhead goes down.

What are the performance implications of this kind...

2008-03-15T08:52:00.000-04:00

What are the performance implications of this kind of file system? Would seeking into the middle of a large file require you to read all the blocks from the beginning of the file to follow the metadata chain? How about appending to the end of a big file?

How much disk space would this kind of extensive metadata use, compared to something like ext3?

@mike.w.meyer: I don't believe this is a concern i...

2008-02-17T09:06:00.000-05:00

@mike.w.meyer: I don't believe this is a concern in practice, since it's far more common to load the data first into the kernel's buffer cache. The buffer cache can certainly handle some of the buffers being label blocks, so it would still be a sequential transfer.

Interleaving data and metadata also hoses the perf...

2008-02-15T23:42:00.000-05:00

Interleaving data and metadata also hoses the performance of
multi-block (not even large) transfers. If I don't do that, I can just
point the disk controller at consecutive chunks of RAM, and let it
load blocks directly into the users output buffer. With metadata at
the start of the block, I have to put the block in an intermediate
buffer in order to copy out just the data.

@fanf: Placing a block full of N labels every N da...

2008-02-15T19:13:00.000-05:00

@fanf: Placing a block full of N labels every N data blocks would address that problem.

One reason against block labels is that they inter...

2008-02-15T17:51:00.000-05:00

One reason against block labels is that they interleave data and metadata, so users can't mmap files and the OS can't have a unified buffer cache.

@seregine: Sure, but the traditional Unix file int...

2008-02-12T06:19:00.000-05:00

@seregine: Sure, but the traditional Unix file interface doesn't provide an "insert" operation anyway. "Inserting" at the beginning of the file is accomplished by writing the entire file out again at a different offset anyway.

This is why MP3 tags are usually placed at the end of the MP3 file, making them easier to edit.

Interesting. So if I insert a block at the beginni...

2008-02-11T22:37:00.000-05:00

Interesting. So if I insert a block at the beginning of a 1GB file, the FS has to write to every other block to update its offset?

the reason this doesn't matter at all is because d...

2008-02-11T13:08:00.000-05:00

the reason this doesn't matter at all is because disks don't fail in such a way as to make it matter. I.e., if you lose a few blocks, it is VERY LIKELY you've lost a lot of blocks, or that entire sectors are unreadable. Studies of disk failures also indicate that once you've lost a few sectors, you are likely going to lose a lot more soon (because such errors are due to platter warpage, foreign material, head alignment, etc).

Unix's scheme of keeping multiple copies of inode's is actually much more reliable in dealing with such situations.

Of course, with the move to solid state drives, maybe Lampson and Sproull's method deserves another look (anyone have any pointers to research on flash drive failures?).