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 concurrencies. > 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 (828)862-5554 www.pari.edu