Matt Dillon wrote:
>
> :
> :This information is in fact correct. Have a look at the FreeBSD link(2)
> :man page:
> :
> :LINK(2) FreeBSD System Calls Manual
> :LINK(2)
>
> Andre, I think there *might* be a dozen people in the world that
> understand UFS/FFS better then I do, but none of them have posted to
> this thread.
>
> Believe me when I say that there is no metadata ordering guarentee
> in the case of a crash. Yes a standard UFS/FFS will do synchronous
> metadata updates for certain operations. No, this does not guarentee
> metadata ordering.
OK, then I believe you.
But please answer me one question: Is the link() call atomically in
FFS/UFS w or w/o softupdates? Meaning when the call returns the meta-
data is written to stable storage like with fsync()?
Only this answer is needed for qmail operation.
--
Andre
> There has been talk of providing system calls to allow user programs
> to request ordering semantics for certain operations, but nobody has
> actually implemented anything. Most of the discussion has been centered
> on having calls to guarentee file write ordering between a set of
> open descriptors for databases.
>
> As I said, a journaled filesystem can theoretically make metadata
> ordering guarentees, but actually doing so creates massive performance
> and scaleability issues that aren't apparent until you really start
> pounding the filesystem. It *CAN* be done efficiently, but only if
> you have a significant amount of non-volatile memory store to hold
> the journal. ReiserFS might do it right now, as a side effect, but if
> it does it faces serious scaleability issues.
>
> Softupdates can also theoretically order [meta]data, using dependancies.
> It is a very difficult problem to solve and it doesn't do it now. All
> softupdates does is guarentee filesystem consistency in the case of a
> crash and certain guarentees for what will be crash-recoverable when you
> do an fsync().
>
> -Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
