Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
Better than POSIX?
Posted Mar 18, 2009 0:36 UTC (Wed) by quotemstr (subscriber, #45331)
Besides --- UFS users don't complain about zero-length orphans, so the filesystem must be doing something right. :-)
Posted Mar 18, 2009 0:49 UTC (Wed) by bojan (subscriber, #14302)
I'm just poking fun, sorry ;-)
Posted Mar 19, 2009 17:19 UTC (Thu) by anton (guest, #25547)
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.
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 orphans
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)
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.
Posted Mar 23, 2009 9:45 UTC (Mon) by anton (guest, #25547)
soft update not providing true atomic rename?
Posted Mar 23, 2009 11:31 UTC (Mon) by xoddam (subscriber, #2322)
The (sketchy) lecture notes linked in quotemstr's first post end with two points of limitations of soft updates:
>Limitations of soft updates:
> * Not as general as logging, e.g., no atomic rename
> * Metadata updates might proceed out of order
> - create /dir1/a than /dir2/b
> - after crash /dir2/b might exist but not /dir1/a
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 ;-)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds