Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 4 Oct 1998 03:55:51 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        julian@whistle.com (Julian Elischer)
Cc:        gibbs@plutotech.com, Don.Lewis@tsc.tdk.com, current@FreeBSD.ORG
Subject:   Re: Softupdates, filesystem safety and SCSI disk write caching
Message-ID:  <199810040355.UAA24036@usr06.primenet.com>
In-Reply-To: <Pine.BSF.3.95.981002135812.15828E-100000@current1.whistle.com> from "Julian Elischer" at Oct 2, 98 02:22:01 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> No this is not what softupdates expects..
> 
> It expects that data blocks are written before metadata blocks.
> (for writing files)
> 
> An example of some of the dependencies for writing a file B are:
> 
> directory blocks depend on
> inode blocks, which depend on
> indirect blocks, which depend on
> datablocks

I think it is important to interject something here:

	Not only does soft updates protect the filesystem integrity
	by way of ordering metadata, it *also* protects user data
	integrity.  This is *more* than the standard "no options"
	mount used to do; it is closer to what a "sync" mount
	does.

Again, in English: soft updates is *better* than sync metadata with
async data.


The ability to protect user data was why I was initially so adamant
about a generic implementation of a dependency graph event
reconciliation registration mechanism.

If I could register a new dependency type called "transaction", I
could export a transactioning interface to user space.

A transaction, in this sense, is an implied relationship between
two or more files data contents.

As it is, I can use the old fashioned technique, and do fsync()
calls; this is, however, not nearly so satisfying.  8-(.


> This is not acceptable to softupdates. (as defined by McKusick, Ganger and
> Pratt)

Uh, "Patt". 8-).


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810040355.UAA24036>