| |||||||||||||
I don't think OSF/1 aka Digital Unix aka Tru64 Unix ever had soft updates.I don't think OSF/1 aka Digital Unix aka Tru64 Unix ever had soft updates.Posted Mar 23, 2009 6:01 UTC (Mon) by xoddam (subscriber, #2322)In reply to: Better than POSIX? by anton Parent article: Better than POSIX?
I think the OP was speculating about the utility of UFS as currently supplied with most free BSDs and therefore making up the vast majority of contemporary UFS users.
Soft updates were first implemented on top of 4.4BSD (but weren't part of the distribution), first described in a paper in 1994 and first widely distributed as part of FreeBSD 4.0 in 2000.
Your complaint (linked above, not dated) seems to be about UFS on the DEC distribution of OSF/1 for its Alpha machines. OSF/1 had the option of traditional BSD-style UFS (synchronous metadata with async data) or the journaling filesystem AdvFS. (You initially had to pay extra for AdvFS. It was GPLd last year and is on SourceForge).
So if you used UFS on Tru64 or whatever it was called at the time, you didn't have soft updates like you do on today's *BSD. You had synchronous metadata updates with asynchronous data writes. OSF/1 never adopted soft updates because it already had a good journaling solution years beforehand.
(Log in to post comments)
I don't think OSF/1 aka Digital Unix aka Tru64 Unix ever had soft updates. Posted Mar 23, 2009 9:45 UTC (Mon) by anton (guest, #25547) [Link] Yes, my complaint was about UFS with synchronous metadata updates, not with soft updates (indeed I mention soft updates as a correct solution). My complaint just refutes the no-complaints claim of the OP, and weakens his insinuation that UFS with soft updates still zeroes files and we just don't hear about it.
soft update not providing true atomic rename? Posted Mar 23, 2009 11:31 UTC (Mon) by xoddam (subscriber, #2322) [Link]
Methinks "insinuation" is a bit strong. If anything, Daniel was suggesting that UFS-with-soft-updates gets the balance right with respect to users' data not going missing.
The (sketchy) lecture notes linked in quotemstr's first post end with two points of limitations of soft updates:
>Limitations of soft updates:
As has been explained elsewhere, rename on early Unix implementations was a two- or three-step process: unlink any existing file at the target path, hard-link the file at the source path to the target path, and finally unlink the source path. The target path would briefly be absent (as observeable by concurrent processes, nothing to do with crash recovery) and the source file was briefly visible at two locations. Atomic replace was introduced to avoid the two obvious race conditions: a reader might find nothing at the target location, or another updater might open the source path with O_TRUNC and thereby inadvertently truncate the target file.
It's possible (pure speculation on my part here, I haven't actually used soft updates or read the code) that the atomicity not provided by UFS-with-soft-updates amounts to a chance that the source file may end up linked at both the source and target paths. This is likely if the rename is moving the file from one directory to another, as the two directories are likely to be stored at different locations on disk.
Updating the target directory first, with atomic replacement of an existing file at that path but delayed deletion of the source path, satisfies the important condition that the target file never disappear, while violating the letter of the atomic rename contract.
The race condition risking truncation of target file when the source path is opened O_TRUNC may still exist, but only after a crash as the atomic semantics pertain on a running system.
Maybe there are no complaints from BSD users because they're so l33t they never crash: they don't run out of battery or kick out power cords or use unstable video and wireless drivers. Or maybe, just maybe, soft updates are as cool as they say ;-)
|
|||||||||||||