Re: Safe File Update (atomic)
On Fri, Dec 31, 2010 at 3:44 PM, Enrico Weigelt <weigelt@metux.de> wrote:
> * Olaf van der Spek <olafvdspek@gmail.com> schrieb:
>
>> > Well, they're an fundamental concept which sometimes *IS* significant
>> > to the applications. It's very different from systems where each
>> > file has exactly one name (eg. DOS/Windows) or where there're just
>> > filesnames that point to opaque stream objects that can be virtually
>> > anything (eg. Plan9).
>>
>> Sometimes, indeed. This number of times should be as low as possible.
>
> These cases aren't that rare. Windows, for example, tends to deny
I mean that apps shouldn't have to know about inodes.
> renames on open files, as they're also identified by the filename.
Not true. Renaming a running executable works just fine, for example.
> (yes, there're other solutions for this problem, eg. having some
> internal-only inode numbering, etc).
>
> It's important to understand, that on *nix, filenames are not representing
> the files directly, but just a pointer to them (somewhat comparable
> to DNS entries), where other platforms directly use the filename as
> primary identification (sometimes even as primary key). This has great
> implications on the semantics of the filesystem.
>
>> > Why not designing an new (overlay'ing) filesystem for that ?
>>
>> Increased complexity, lower performance, little benefit.
>
> Why that ? Currently applications (try to) implement that all on
> their own, which needs great efforts for multiprocess synchronization.
> Having that in a little fileserver eases this sychronization and
> moves the complexity to a single point.
I mean compared to implementing it properly in the kernel.
Olaf
Reply to: