* Matt Dillon <[EMAIL PROTECTED]> [010206 12:19] wrote:
> :> banging on unrelated areas of the filesystem in parallel, and an
> :> fsync() of one descriptor would have to wait for the entire filesystem
> :> to reach a synchronization point to guarentee metadata update ordering.
> :> This creates a serious scaleability issue within a filesystem!
> :
> :Yes, my understanding of the meaning of "ordered meta-date update" as
> :I have grasped it from Terry's rants in the past years is not that all
> :meta-data updates on a filesystem have to be done one-after-the-other
> :but ordered in respect to each other; That a link() happens before a
> :unlink() on the same file. Does this make sense?
>
> If you link() in directory A and unlink() in directory B, you are not
> guarenteed that the link in A will sync to the disk before the unlink
> in B with regards to a crash occuring.
I dont' think the "link() in directory A" syscall will return until
it is sync'd (noasync UFS/FFS)! Therefore the unlink() can't happen
unless it's being done by another process.
Yes, other activity in the same dir can cause corruption, but meta
data updates are done via sync writes that won't return until they
are complete.
Except for corruption, they are ordered. Since you can't IPC during
a syscall reliably (you can't signal before because then you have
a race, and you can't signal during because the kernel has a grip
on your context) they are ordered when related.
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
