Re: Safe File Update (atomic)
On Sun, 02 Jan 2011, Ted Ts'o wrote:
> And of course, Olaf isn't actually offerring to implement this
> hypothetical O_ATOMIC. Oh, no! He's just petulently demanding it,
> even though he can't give us any concrete use cases where this would
> actually be a huge win over a userspace "safe-write" library that
> properly uses fsync() and rename().
Olaf, O_ATOMIC is "difficult" in the kernel sense and in the long run. It
is an API that is too hard to implement in a sane way, with too many
boundary conditions.
OTOH, you don't need O_ATOMIC. You need a way for easy application access
to a saner/simpler way to deal with files that require atomic replacement.
Time to switch to a plan B that can achieve it. Do not lose track of your
final goal, and stop wasting time with O_ATOMIC (and aggravating fs
developers, which can only hurt your goal in the end).
Maybe there are ways to actually let the kernel detect usage patterns and do
the right thing, but nobody found any that is complete (and the incomplete
ones are implemented in ext3 and ext4 AFAIK).
If an userspace library is built to do all the dances required using only
POSIX APIs (you can use extensions where they are available to enhance
performance) you will have an EXACT list of boundary conditions and choke
points.
With that exact list of requirements in hand and something that can be
easily regression-tested, it gets a LOT easier to talk to any fs developer
and to the glibc developers, and come up with the kernel and glibc
enhancements needed to accelerate it (or remove boundary conditions) that
are acceptable to both sides.
In the end, because POSIX _is_ crap in many ways, you will have some
boundary conditions that cannot be removed or worked around. It is likely
that they will not be so serious flaws that it will make the whole idea
unusable. Maybe they will apply only to some filesystems (just like right
now there are some things you simply don't use NFSv3 for).
If you have other ideas that have no weird side-effects or troublesome
semanthics, I am sure you'd have a better chance of it happenning. They're
probably not going to take the form of open() flags for the same reason
O_ATOMIC has problems, but who knows. If I had a good idea about how to
solve this problem, I'd have already written paper about it or something.
Well, that's it. I have nothing else to contribute to this thread.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: