| |||||||||||||
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 9:45 UTC (Mon) by anton (guest, #25547)In reply to: I don't think OSF/1 aka Digital Unix aka Tru64 Unix ever had soft updates. by xoddam Parent article: Better than POSIX? 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.
(Log in to post comments)
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 ;-)
|
|||||||||||||