Re: dateisystem

In list.de-bsd-questions you wrote (14 Sep 1999 22:24:58 +0200):
> SOFTUPDATES kein Thema, sofort und jederzeit. Und wann passt jemand den
> fsck darauf an? Dann hat man, so denn ein Absturz eintreten sollte, wieder
> schneller die Kiste oben. Oder ist das aufgrund der verwendeten
> Verwaltungstechnik nicht sinnvoll?

Ich erlaube mir mal, zu dem Thema ein Posting wiederzugeben,
das kürzlich in der Hackers-Liste kam (leicht gekürzt):

<quote>

>From atlantis.rz.tu-clausthal.de!not-for-mail Tue Sep 14 23:52:12 1999
Path: atlantis.rz.tu-clausthal.de!not-for-mail
>From: Julian Elischer <julian(at)whistle.com>
Newsgroups: list.freebsd-hackers
Subject: Re: SOFTUPDATES and fsck
Date: 14 Sep 1999 10:06:02 +0200
Organization: FreeBSD.ORG
Approved: newsgate(at)atlantis.rz.tu-clausthal.de
Message-ID: <7rkvla$26fn$1(at)atlantis.rz.tu-clausthal.de>
Reply-To: freebsd-hackers(at)FreeBSD.ORG
NNTP-Posting-Host: localhost
Xref: atlantis.rz.tu-clausthal.de list.freebsd-hackers:33549

On Tue, 14 Sep 1999, Thomas Graichen wrote:
> 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

</quote>

Gruß
   Oliver

-- 
Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany
(Info: finger userinfo:olli(at)dorifer.heim3.tu-clausthal.de)
"In jedem Stück Kohle wartet ein Diamant auf seine Geburt"
                                         (Terry Pratchett)
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message