Hey gang,
Nice stuff!
read on
-rohit
-----Original Message-----
From: J Wunsch <[EMAIL PROTECTED]>
Newsgroups: comp.unix.bsd.freebsd.misc
Date: Sunday, February 27, 2000 7:40 PM
Subject: Re: FreeBSD Filesystem?
>Don Quixote <[EMAIL PROTECTED]> wrote:
>
>> Could you (Or anyone following this thread.) explain what
>> the differences are?
>
>Traditional UFS (as it's the default e. g. in FreeBSD, but also in
>Solaris, for one other example) performs all metadata updates
>synchronously to disk, in order to ensure the on-disk state to be
>always consistent. `metadata' means all updates to i-nodes, directory
>blocks etc. Should your system crash while some update is in
>progress, fsck will be able to fix any further damage when it runs
>upon reboot. This is a time-consuming process, but so far has proven
>to provide a good filesystem stability.
>
>Just for the record, non-metadata updates, i. e. ordinary file data
>are by default always backed up asynchronously, so if you power off
>your machine during some operation, you can of course lose file data,
>but the structure of the filesystem is supposed to always be
>repairable. In 4.4BSD, you can even mount a filesystem completely
>synchronously using ``-o sync'' at mount time (which is _not_ the
>opposite of ``-o async''). Of course, this will make any write
>operation dog slow.
>
>Now if you're performing heavy structural changes to your file system,
>like `rm -r *' somewhere, or like unpacking a tar archive consisting
>of numerous small files, those synchronous metadata updates will
>heavily slow down the entire process. To remove a file, first the
>directory entry is being removed, thus the entire directory block will
>be written back, this causes a directory access time update, so the
>directory i-node block needs to be rewritten. Then, if the file's
>i-node has lost all links (and has no open internal references in the
>kernel), the file can be removed, which will happen by deallocating
>all blocks, writing the block map back, and finally freeing the
>i-node. Now if it comes to the next file in the same directory, the
>same procedure happens etc., thereby probably touching the very same
>directory block (and directory i-node block) over and over again.
>
>There are several approaches out of this dilemma. The most aggressive
>approach is that you simply don't care about structural integrity of
>your on-disk state, and simply queue up all metadata updates for
>asynchronous backup (like with ordinary data blocks). Naturally, the
>sequence those updates will be written to disk is fairly random, so
>you cannot ensure a consistent on-disk state, and thus you cannot
>algorithmycally ensure the filesystem is even repairable at all if the
>system crashes between the structural change and the actual back-up of
>the metadata updates to disk. OTOH, this approach is seemingly fast.
>This approach is the default for Linux' ext2fs, and you can have it
>for FreeBSD's UFS by mounting it ``-o async''. (Note that it's
>possible to only temporarily mount -o async in case you're planning
>some heavy structural change and take the risk of damage for that time
>into account, and just revert to the traditional behaviour later by
>``-o noasync''.)
>
>Other approaches are `logging', where metadata updates are written
>synchronously into an `intent log' which is a small area on the disk
>so seek times for logging transactions are fairly low compared to the
>full-disk seek times needed for the classical synchronous updates.
>The updates are later asynchronously moved to their regular disk
>position, and cleared from the intent log. (This is sometimes also
>called `journalling'.) This approach is e. g. taken by Veritas File
>System (VxFS). The advantage is increased metadata performance for
>massive structural changes using an algorithm that's not too difficult
>to implement (and thus not too error-prone). The drawback is that all
>metadata updates go twice to disk, so for smaller updates, performance
>is evern worse.
>
>Kirk McKusick analyzed the situation and implemented another strategy
>he describes as `soft-updates', or `ordered metadata updates'. All
>metadata updates are stored in memory structures first (so the on-disk
>state remains as if nothing had happened at all). They are later
>backed up to disk considering all their interdependencies. So if you
>rm -r * something, it often happens you have to update the same
>directory block and i-node many times -- all this can happen in memory
>as long as the updates didn't go out to disk. This basically achieves
>the same speed as -o async, but with the same structural safety as the
>classical synchronous updates. The drawbacks are a larger memory
>footprint (Kirk recommends to not use soft-updates on machines with
>less than 32 MB of memory), and a much more complicated code compared
>to the `logging' approach. Anyway, the code complication problem has
>basically been solved, Kirk contributed his code to the community a
>while ago (although by now not for commercial redistribution)...
>
>--
>cheers, J"org / 73 de DL8DTL
>
>[EMAIL PROTECTED] -- http://www.sax.de/~joerg/ -- NIC:
JW11-RIPE
>Never trust an operating system you don't have sources for. ;-)
To subscribe / unsubscribe goto the site www.ilug-bom.org ., click on the mailing list
button and fill the appropriate information
and submit. For any other queries contact the ML maintener
