[CentOS] Re: centos] 4.4 upgrade problems)

Mon Sep 11 12:28:02 UTC 2006
Lamar Owen <lowen at pari.edu>

On Sunday 10 September 2006 20:45, R P Herrold wrote:
> On Sat, 9 Sep 2006, Lamar Owen wrote:
> > On Tuesday 05 September 2006 22:35, R P Herrold wrote:
> >> This bug hinges, very much, on the non-atomic nature of
> >> 'hot' system updates, and the fact that the yum-needed,
> >> sqlite-maintianed cache of packages got munged half way
> >> through, to reproduce.

> > Sounds like a database type issue; ... That is, a filesystem
> > on ACID.  (Atomicity, Consistency, Isolation, Durability:
> > the magic mantra of database management).

> *flashback* Acid - Berkeley - BSD -- coincidence? I think
> _not_.  ;)

As long as the filesystem doesn't hallucinate, we're ok.

> *cough* Nothing so complex needed here; a simple early flock
> holding upon the sqlite-python verson with which the cache was
> created would have sufficed, in thinking about the bugreport.

For your original report, probably so.  But I did the update of those bits 
first, and got no errors or 'hung' yum.

> As to ACID, a interesting sidelight (as to MySQL, not the
> PostgreSQL which Lamar mentioned).  It turns out that even
> with use of the Innodb backend engine in MySQL as we ship it
> in CentOS, and as inherited from the upstream PNAELV, for
> perfomance reasons, full ACID compliance is turned off.

Why does this not surprise me?  PostgreSQL doesn't even have an option to turn 
off ACID-compliance; and performance is competitive, especially under large 

> As to using a database backend filesystem, with full ACID
> consistency enabled, I think a certain OS vendor in Redmond
> had to backaway from that featureset bulletpoint item in a
> somewhat delayed upcoming release.

:-)  I figured someone would bring up WinFS.  Wouldn't it be a serious coup 
for the open source community to do what MS could not?

> One had better be willing 
> to suffer performance hit collateral damage with the present
> state of the implementaion art. Think of inviting a gorilla
> over, to use an anvil to swat a fly in the kitchen.  ouch.

Nah.  Think of a flyswatter that could, if needed, reconstitute that swatted 
fly if, perchance, it turned out to be a useful insect.  Hmm, makes undelete 
real easy, too.  Makes secure wiping harder, though.  NILFS is part of the 
way there.  Shoot first, ask questions later, rollback if needed.

There probably would be a performance hit to a degree; but, again, 
PostgreSQL's performance under MVCC is quite good, and competitive even with 
MySQL's MyISAM tables under large concurrencies with an even mix of readers 
and writers.
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772