Re: Safe File Update (atomic)
On Mon, Jan 3, 2011 at 4:25 AM, Ted Ts'o <tytso@mit.edu> wrote:
> On Sun, Jan 02, 2011 at 04:14:15PM +0100, Olaf van der Spek wrote:
>>
>> Last time you ignored my response, but let's try again.
>> The implementation would be comparable to using a temp file, so
>> there's no need to keep 2 g in memory.
>> Write the 2 g to disk, wait one day, append the 1 k, fsync, update inode.
>
> Write the 2g to disk *where*? Some random assigned blocks? And using
A random allocation strategy would work, but better options are available. ;)
> *what* to keep track of the where to find all of the metadata blocks?
Implementation detail, but a new temp inode might work.
> That information is normally stored in the inode, but you don't want
> to touch it. So we need to store it someplace, and you haven't
> specified where. Some alternate universe? Another inode, which is
> only tied to that file descriptor? That's *possible*, but it's (a)
> not at all trivial, and (b) won't work for all file systems. It
> definitely won't work for FAT based file systems, so your blithe, "oh,
> just emulate it in the kernel" is rather laughable.
You'd have to decide what you want to do in that case. One option is
to fallback to the non-atomic variant.
Another is to fallback to a temp file with a name. But then I assume
the kernel is still able to preseve meta-data and to ensure atomic
operation.
> If you think it's so easy, *you* go implement it.
>
>> > How exactly do the semantics for O_ATOMIC work?
>> >
>> > And given at the momment ***zero*** file systems implement O_ATOMIC,
>> > what should an application do as a fallback? And given that it is
>>
>> Fallback could be implement in the kernel or in userland. Using rename
>> as a fallback sounds reasonable. Implementations could switch to
>> O_ATOMIC when available.
>
> Using rename as a fallback means exposing random temp file names into
> the directory. Which could conflict with files that the userspace
> might want to create.
They don't need to be in the same dir.
> It could be done, but again, it's an awful lot
> of complexity to shove into the kernel.
That's unfortunate but I think the only option.
>> > highly unlikely this could ever be implemented for various file
>> > systems including NFS, I'll observe this won't really reduce
>> > application complexity, since you'll always need to have a fallback
>> > for file systems and kernels that don't support O_ATOMIC.
>>
>> I don't see a reason why this couldn't be implemented by NFS.
>
> Try it; it should become obvious fairly quickly. Or just go read the
> NFS protocol specifications.....
In that case: update the NFS protocol (yes, long-term solution)
>> As you've said yourself, a lot of apps don't get this right. Why not?
>> Because the safe way is much more complex than the unsafe way. APIs
>> should be easy to use right and hard to misuse. With O_ATOMIC, I feel
>> this is the case. Without, it's the opposite and the consequences are
>> obvious. There shouldn't be a tradeoff between safety and potential
>> problems.
>
> Application programmers have in the past been unwilling to change
> their applications.
Why not?
> If they are willing to change their applications,
> they can just as easily use a userspace library, or use fsync() and
> rename() properly. If they aren't willing to change their programs
Fsync, rename (and preserving meta-data) is a lot more complex then
their current code which for me would be a disadvantage.
O_ATOMIC is a single flag that doesn't increase their code complexity.
A new lib dependency is also a disadvantage.
> and recompile (and the last time we've been around this block, they
> weren't; they just blamed the file system), asking them to use
> O_ATOMIC probably won't work, given the portiability issues.
If they're happy to blame the FS they're probably also happy to
#define O_ATOMIC 0 if O_ATOMIC isn't available.
>> Not true. I've asked (you) for just such a lib, but I'm still waiting
>> for an answer.
>
> Pay someone enough money, and they'll write you the library. Whining
> about it petulently and expecting someone else to write it is probably
> not going to work.
Given that the issue has come up before so often, I expected there to
be a FAQ about it.
I didn't say you had to write such a lib, just saying you weren't
aware of any existing lib would've been enough.
But given that you have so much experience on this issue, pointing to
a few apps that got this right shouldn't be so hard.
Unless getting it right is currently impossible...
> Quite frankly, if you're competent enough to use it, you should be
> able to write such a library yourself. If you aren't going to be
> using it yourself, they why are you wasting everyone's time on this?
Because this is still a real world problem that needs to be solved.
Stopping this conversation isn't going to solve the problem.
Olaf
Reply to: