18 Jul
2014
18 Jul
'14
2:16 a.m.
I think that's is a problem in that it needs to be data blocks, inodes, and
finally superblocks to do the least damage in a crash.
It was a nice piece of work on George's part at the time. I remember the
USENIX when he talked about it and many of us had an aha style moment. I
remember talking to dmr about it dinner that night and he made a comment
about it being slightly embarrassing that nobody had looked it / paid
attention to it before.
Those were the days of UNIX vs RSX or UNIX vs VMS and remember one of the
prime knocks that the UNIX haters would say was that the UNIX (FS) was not
reliable. Between Ted's fsck to replace the Xcheck() family and ghg's
kernel changes people started to stop making that claim. UNIX was just as
good if not better than the "commercial" OSses.
Clem
The other tool that showed up around then was fsdb, but I admit I never
really felt comfortable working with it. I did it so rarely and I always
had the manual open. But it was so easy to do more damage with it.
Fortunately, fsck usually was good enough.
On Thu, Jul 17, 2014 at 2:04 PM, Ronald Natalie <ron(a)ronnatalie.com> wrote:
Sync works like this:
1. If the update-lock is already set, just return.
2. Set the lock
3. Write any superblocks that are marked as modified
4. Wirte any inodes that are marked as needing update
5. Clear the lock.
5 Write all the dirty blocks in the buffer cache (which it does at
spl6());
Once it returned you should be good to go. The only time typing multiple
ones helps is if there was other activity going on while you were trying to
do all this.