On Tue, 14 Sep 1999, Thomas Graichen wrote:
> hello ...
>
> maybe this belongs more to fs than to hackers - but maybe this is
> the correct place here for it ...
>
> i've just read the soft updates paper from:
>
> http://www.ece.cmu.edu/~ganger/papers/CSE-TR-254-95/
>
> at which the soft updates README's in the FreeBSD tree point and ran
> across the following lines in the section 5.1 "file system recovery":
>
> "With the conventional implementation, the fsck utility must be run on
> a file system before it can be mounted after any system failure. By
> guarateeing that the on-disk metadata can always be used safely (except
> when media corruption destroys live metadata), our soft updates im-
> plementation lifts this requirement. A file system can be safely
> mounted and used immedeately after most system failures, but may
> contain several inconsistencies:
>
> * unused blocks may not appear in the free space maps
>
> * inode link counts may exceed the numer of associated directory
> entries
>
> * unreferenced inodes may not appear in the free inode maps
>
> One can run the fsck utility on the filesystem, when convenient, to
> reclaim unreferenced ressources and correct link counts. ..."
>
> at another point it is mentioned that it should be doable to write
> an fsck tool which can do those corrections in background while the
> filesystem is mountet read/write ...
>
> now my question: how much of this applies to the soft updates im-
> plementation in FreeBSD ? - might this eventually open the door
> to an fsck free bootup after a system crash without having to
> write a journaled filesystem for FreeBSD ? - i think this is
> one point which gets more and more important on systems with
> several 100 gb disk space and thus enormous fsck times after
> a failure
>
> can anyone - who is deep in the details of the FreeBSD soft updates
> implementation (julian, matt, kirk) give some comments on this ?
The trouble is that any fsck is a user process, and can not therefore get
an single instantanious snapshot of the filesystem.
teh delays make it impossible to do this 'online background' fsck without
serious risk of actually freeing blocks that the filesystem is busy
marking in use, due to race conditions....
Kirk is working on this. His scheme is to actually checkpoint the
filesystem, and record all metadata changes that occur after the
checkpoint, in a file INSTEAD OF in the filesystem.
the result is that the filesystem is in effect frozen, even though
metadata changes are happenning.
tehn when the fsck complets and the filesystem is marked clean,
all updates in the log file are played back into the live filesystem,
so that it 'catches up'. When all logged actions have been played out,
then the filesystem is 'unfrozen' and continues a sper normal.
New metadata actions occuring while the log is being replayed
might be placed on the end of the log, or allowed directly into the
filesystem. I don't know which....
julian
>
> a lot of thanks in advance
>
> t
>
> --
> [EMAIL PROTECTED]
> innominate AG
> networking people
> fon: +49.30.308806-13 fax: -77 web: http://innominate.de pgp: /pgp/tg
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
