| |||||||||||||
|
| |||||||||||||
Better than POSIX?Better than POSIX?Posted Mar 18, 2009 0:36 UTC (Wed) by quotemstr (subscriber, #45331)In reply to: Better than POSIX? by bojan Parent article: Better than POSIX? Well, what's confusing is that it should, as I understand soft-updates --- it maintains a dependency graph of required metadata updates, and writes to disk in such a way that at each step, the system is consistent. I don't see why such a scheme wouldn't automatically give you at least a metadata-level atomic rename, so I was asking for clarification on what those notes meant. Besides --- UFS users don't complain about zero-length orphans, so the filesystem must be doing something right. :-)
(Log in to post comments)
Better than POSIX? Posted Mar 18, 2009 0:49 UTC (Wed) by bojan (subscriber, #14302) [Link]
Key word: possible.
I'm just poking fun, sorry ;-)
Better than POSIX? Posted Mar 19, 2009 17:19 UTC (Thu) by anton (subscriber, #25547) [Link] Well, what's confusing is that it should, as I understand soft-updates --- it maintains a dependency graph of required metadata updates, and writes to disk in such a way that at each step, the system is consistent. I don't see why such a scheme wouldn't automatically give you at least a metadata-level atomic rename, so I was asking for clarification on what those notes meant.Soft updates is an enhancement of a file system that does update-in-place. Certain things are hard or impossible to do in that setting. In particular, rename requires updating to different places, so if you update one place after the other (as you have to do with in-place updates), there is a time span when one update has happened, but not the other. You can use a journal for an in-place update system to work around this: write the rename operation atomically into the journal, then perform the individual updates, then clear that journal entry. In crash recovery replay the outstanding journal entries. Or you can use a copy-on-write file system: there you write the changes to some free space, and when you have reached a consistent state, commit the changes by rewriting the root of the file system. Besides --- UFS users don't complain about zero-length orphansWrong!
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) [Link]
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.
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 (subscriber, #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 ;-)
|
|
||||||||||||