[198] in 6.033-lab
fs proposals
daemon@ATHENA.MIT.EDU (Benjie Chen)
Mon Apr 10 16:01:14 2000
From: Benjie Chen <benjie@cag.lcs.mit.edu>
Message-Id: <200004102001.QAA13020@amsterdam.lcs.mit.edu>
To: 6.033-lab@MIT.EDU
Date: Mon, 10 Apr 2000 16:01:02 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Comments on proposal:
Most people had reasonable data structure and layout. Most of the
comments are on recovery. A couple of things:
1. You need to worry about order of your write operations. For example,
if you delete file 1, then add file 2, you have to make sure that
file 2 does not reference a data block used by file 1 if your
computer crashes between delete and add.
You can always recover your data structures to a consistent state
(i.e. no inode or data blocks missing) w/o worrying about write
ordering. But your FS won't be correct: for example, two files
better not share the same inode if they weren't suppose to.
About the only thing you don't need to worry about is the correct-
ness of your data blocks, in the sense that if your data block is
clobbered because crash occured in the middle of a write to that
data block, you don't need to worry about recovery from that block
(although if you are willing to use twice the disk space, you can
device a nice algorithm that will guarantee that you will either
have old or new data, but never something in between).
2. Don't forget that you need to make sure you don't loose any inodes
and data blocks when a system crashes. An inode/datablock should
either be referenced or in free-list.
3. A lot of proposals mentioned the use of a dirty bit. It needs to
be written between a write and after a complete file operation is
done. If you are going to use this bit, you need to make sure you
set and clear it at the right place. Some people didn't tell me
how you were going to do that.
Also, you should remember not to use/trust metadata in your
superblock across crashes. Reconstruct them first.
4. You should duplicate your superblocks just beause that's what
real fs do. It's not complicated, so do it.
5. Most proposals don't mention this, but the hardest recovery is
not growing and shrinking files, but rather directory operations
like creating and deleting new files.
6. Don't worry about extra features or recovery performance for now.
But you should make sure your normal fs operations are reasonably
good.
7. IMPORTANT: since you will have write ordering, you need to know
that when you call bwrite, it does a write() system call, which is
not guaranteed to write data to disk (may get cached in real buffer
cache). You therefore should create a bsync() interface that calls
the fsync() system call to flush buffer cache between writes that
need to be ordered.
8. Don't need to worry about vnodes. If you don't know what I am
talking about, don't worry.
9. If you haven't thought about recovery (you know who you are =)),
you should think about it. It may affect how your fs is written.
Okay. If you have questions, please come and bug me.
Yeah yeah, I am working on your webproxy grading.
Benjie
--
Benjie Chen
benjie@lcs.mit.edu
