On Tue, 25 Nov 2008 12:33:26 -0800, Darren New wrote:

> Jim Henderson wrote:
>>> No, I  mean you can make it generic. Instead of looking at each of the
>>> 30+ possible causes of error, you can say "Any error rolls back the
>>> changes."
>> 
>> So like "an error occurs, let's ask the user what should happen"? 
>> Which is what it does. :-)
> 
> Uh, no. That's kind of my point. You can set things up such that it
> works *JUST LIKE* a database transaction. Something fails in the middle,
> and the system automatically puts things back to the way they were.

I prefer that the system let me know about an error condition so I can 
correct the underlying issue, when it comes to things like filesystem 
errors.

>> That would likely happen with a disk full error - if you can't commit
>> one transaction, it's going to be hard to verify and write out the old
>> state as well, no?
> 
> No. Just like a real database system, things don't get updated
> permanently until you're sure it'll work.

A silent failure wouldn't be useful - no indication of success or failure 
would be even more confusing, IMO.

>>> For example, to make things work, you need to up date the executable
>>> and three dynamic libraries. You update the executable, and one of the
>>> libraries, and then your network connection to the machine hosting the
>>> files fails. You can't handle that exception by rolling back your
>>> changes manually.
>> 
>> You can by reinstalling the package, though.
> 
> Only after you get your network connection back. Until then, everyone
> using the machine locally is screwed.

A good case to be made for doing updates on the local machine rather than 
the remote machine.  Like I said, management procedures in place for non-
standard deployments.

>>> Well, yes. That's why you have file system transactions in Windows.
>>> That's kinda exactly my point. If you start a kernel transaction, copy
>>> some files, update the registry, then bomb out, your changes get
>>> rolled back automatically. Just like any other database system, and
>>> regardless of why you bombed out or over which network the files are
>>> mounted.
>> 
>> And on Linux you have ext3, reiser, jfs, and other journaling
>> filesystems.
> 
> 
> 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.

>>> Unless the error is "you pulled the plug" or "the RAID fell over" or
>>> something like that.
>> 
>> If RAID falls over, I'd say you've got a more serious problem on your
>> hands....I've had that happen a few times, and it generally leads to a
>> system reinstall.
> 
> And you've never lost power either, I take it?

Got a system here with a bad power supply, as a matter of fact - and yes, 
it screwed a VMDK file that was open at the time.

You want to implement a filesystem as a database, knock yourself 
out. ;-)  It's overkill for most applications.

>> Sure, and that's what package validation is for
> 
> Except that's a manual post-hoc fix that only works for package
> installs. I'm talking about something that works without intervention on
> a more generic kind of problem.

....

Jim

Post a reply to this message