On Wed, 26 Nov 2008 10:29:51 -0800, Darren New wrote:

> Jim Henderson wrote:
>> Corrupting a single file isn't exactly the same thing as corrupting the
>> filesystem.....cf reference to our previously crashed RAID arrays.
> 
> No. But since the file system already supports not corrupting the file
> system, why wouldn't it support not corrupting the file?

<shrug>  Maybe it does.  I'm not a kernel developer.

>> I've dealt with transactional systems quite a bit, now I see what you
>> were saying - treat the "package" update as a single transaction.
> 
> Yes, exactly. Which is hard to do on a file system that doesn't support
> transactions, because UNIX traditionally layered transactions and
> locking on top of the file system in an application-specific way, just
> like it layers "login" on top of the permission system in an
> application-specific way.

Just at a guess, abstraction layers tend to impact performance.  Look at 
the performance of a fuse-based NFS server vs. a kernel-based NFS server.

>>>>> Cool. What's the system call in Linux that lets me change three
>>>>> files consistemtly?  I.e., I have files /tmp/One, /tmp/Two, and
>>>>> /tmp/Three, and I want to rename them respectively to /tmp/1,
>>>>> /tmp/2, and /tmp/3, and I never want any possibility of an "ls"
>>>>> operation on the /tmp/ directory to show my /tmp/One and /tmp/3 at
>>>>> the same time, or /tmp/1 and /tmp/Three.  Is there some way to
>>>>> accomplish that?
>>>> Again, if it's handled as part of the system update, the updater
>>>> takes care of that for you, not the system.
>>> That didn't answer the question.  How does the updater make sure that
>>> you never see a half-renamed collection of files, even assuming we're
>>> only talking about the updater here?
>> 
>> Because it deals with the individual package updates one RPM or delta
>> file at a time.
> 
> You still didn't answer the question. Look at the actual question:
>      What's the system call in Linux that lets me change three files
>      consistently?
> You said the Linux journaling file systems let you have file system
> transactions. I believe it might be there, but I've never found it; it
> might be something new. What's the system call?

I'm not a kernel developer, so I don't know what the system call is.  
That would be a question for the kernel developers. :-)

>> Where there's a will, there's a way - it is all open source code, so it
>> wouldn't be impossible to implement for someone who was really
>> determined to do so.  :-)
> 
> Sure. But you implied it's already there.

It seems to be IME.  Maybe that's because it's an application-specific 
solution implemented - but I point back to the start of the discussion 
where you cited problems with the SUSE updater application.  I was 
answering that question (at least initially), not getting into a 
discussion of kernel-level system calls for transactional dealings with 
multiple files, because I'm not a kernel guru.

> I just pine for the days when it was possible to write a program that
> ran reliably even in edge conditions, rather than being impossible to
> ensure that things work correctly because the underlying systems are so
> half-ass. :-)

Well, most development is done to the 80/20 rule rather than to "edge 
conditions" for economic reasons (at least that's what I'm told).  OSS is 
a wonderful thing, though, because those who want to develop to those 
"edge conditions" can do so.  :-)

Jim

Post a reply to this message