Re: Safe File Update (atomic)
Ted Ts'o <tytso <at> mit.edu> writes:
> actually. The right answer has been known for decades, and it's is
> very simple; write a temp file, copy over the xattr's and ACL's if you
> care (in many cases, such as an application's private state files, it
> won't care, so it can skip this step --- it's only the more generic
> file editors that would need to worry about such things --- but when's
> the last time anyone has really worried about xattr's on a .c file?),
> fsync(), and rename().
>
> This is *not* hard. People who get it wrong are just being lazy.
IMO calling a recipe containing fsync() "the right answer" is wrong. For the
clear majority of programs waiting for a disk-level write is not the correct
semantics, and using fsync does cause real problems, the recent dpkg issues here
being just one example. IMO telling people to use fsync does more harm than
good; rather we should be telling them to not use fsync unless they really know
what they're doing.
In another post in this thread you also talk about how we've managed to live
with the current functionality for three decades. We've managed to live, but
what exactly is the practice we've lived with? I'd say an essential part of it
has been the recipe of "write temp file + rename", _without_ doing an fsync.
Yes, it may not have been theoretically crash safe on all filesystems; but in
practice, the practice that has allowed things to work for decades, the
filesystems have either been safe or the machines stable enough for it to not
become an issue. If this is no longer true then that is a reason why things are
now different from previous decades and why it's now necessary to add new
functionality.
Reply to: