[CentOS] Re: centos] 4.4 upgrade problems)
lowen at pari.edu
Mon Sep 11 12:28:02 UTC 2006
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
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
More information about the CentOS