On Tue, 25 Nov 2008 17:28:49 -0800, Darren New wrote:

> Jim Henderson wrote:
>> 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.
> 
> Of course you find out about the error. I'd just prefer the system to
> not corrupt the file system when something fails.

Corrupting a single file isn't exactly the same thing as corrupting the 
filesystem.....cf reference to our previously crashed RAID arrays.

>> A silent failure wouldn't be useful - no indication of success or
>> failure would be even more confusing, IMO.
> 
> What makes you think it would be silent??

That seemed to be what you were promoting.  My mistake if I misread.

> I take it you've never used a database that has transactions. What
> happens is you get back a message saying "your transaction failed
> because the disk was full" (or whatever the reason), and you don't have
> to do anything to put your changes back to how they were before you
> started. So if you say (for example) "delete all the .doc files from
> this directory", and one of them isn't deletable, none of them get
> deleted, and you're told which one can't be deleted.

I've dealt with transactional systems quite a bit, now I see what you 
were saying - treat the "package" update as a single transaction.  
Somehow I missed that before.  I guess it's been a busy week trying to 
wrap things up before the holiday. :-)

>> 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.
> 
> Right. That's what I'm saying.  Management procedures to work around the
> lack of functionality.

But there again we're talking about configurations that aren't terribly 
common these days - they used to be, sure - I can remember Sun systems 
with diskless workstations because the versions with disks were so much 
more expensive - so the system was completely remotely booted from a 
4/290.

>>> 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 want to implement a filesystem as a database, knock yourself out.
>> ;-)  It's overkill for most applications.
> 
> Not really. ext3 and reiser and all that are already implemented with
> transactions. You just can't get to them.

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.  :-)

Jim

Post a reply to this message