| |||||||||||||
Better than POSIX?Better than POSIX?Posted Mar 17, 2009 16:25 UTC (Tue) by jeleinweber (subscriber, #8326)Parent article: Better than POSIX? Meanwhile the *BSD crew went to soft updates (non-barrier asynchronous write order dependencies) 10 years ago, and think the Linux filesystem people are crazy for not doing it too. Ted's patches are maybe 25% of the way to what Dr. McKusick described back in 1999. Maybe we should do the other 75% ...
(Log in to post comments)
Better than POSIX? Posted Mar 17, 2009 17:03 UTC (Tue) by quotemstr (subscriber, #45331) [Link] According to http://www.scs.cs.nyu.edu/V22.0480-003/notes/l10d.txt, soft updates doesn't provide atomic rename. (See "limitations".) Can someone who knows more about soft updates elaborate on this point?
Better than POSIX? Posted Mar 18, 2009 0:22 UTC (Wed) by bojan (subscriber, #14302) [Link]
Gosh! A possible file system in another Unix OS that doesn't do the magic? Run for the hills folks! ;-)
Better than POSIX? Posted Mar 18, 2009 0:36 UTC (Wed) by quotemstr (subscriber, #45331) [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.Besides --- UFS users don't complain about zero-length orphans, so the filesystem must be doing something right. :-)
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 (guest, #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 (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 ;-)
Better than POSIX? Posted Mar 18, 2009 2:28 UTC (Wed) by vaurora (guest, #38407) [Link]
Soft updates are brilliant - so brilliant that I'd only want to support a file system using them if I could first clone a bunch of Kirk McKusicks to maintain it.
Better than POSIX? Posted Mar 18, 2009 2:39 UTC (Wed) by quotemstr (subscriber, #45331) [Link]
Why? The concept isn't that complicated.
soft updates Posted Mar 18, 2009 5:15 UTC (Wed) by xoddam (subscriber, #2322) [Link]
The concept isn't complicated, but the implementation is fragile.
Better than POSIX? Posted Mar 19, 2009 9:58 UTC (Thu) by joern (subscriber, #22392) [Link]
Assuming an FFS-style filesystem I agree with you. To my knowledge I have done the only other implementation of soft updates. And it hardly resembles the original because 95% or more of the complexity doesn't exist. Put another way, I could only pull it off by first changing the rules (aka cheating).
soft updates [was: Better than POSIX?] Posted Mar 26, 2009 13:11 UTC (Thu) by doran (guest, #57557) [Link]
For your information, NetBSD just replaced soft updates with journaling.
Soft updates does not understand hardware write-back caches, NetBSD's journaling does. Given than nearly all commodity systems have write back caches at some level in the I/O path nowadays, and need them for good performance, this is important.
Soft updates was quite complicated code with integration issues, making it very difficult to fix some of the bugs with it. This was mainly down to its structure, which was suited to commercialization (soft updates was initially a commercial offering). It was not necessarily tailored to the BSD systems.
Additionally, journaling gives some nice benefits like no fsck, and fully atomic rename. No fsck is important to NetBSD for the embedded role, and elsewhere is a much bigger story than it was when soft updates came about due to the explosion in storage volume size.
|
|||||||||||||