On Saturday 09 September 2006 14:42, Les Mikesell wrote:
> On Sat, 2006-09-09 at 12:43, Lamar Owen wrote:
> > A real transactional filesystem would allow truly atomic system updates.
> > But, of course, there are definite downsides to that.
> I think you are missing the big picture here.
No, I don't think I am. I think you are. The big picture is that yum is not
atomic in its update (not yum's fault, either); lack of atomicity (in my
case) produced a problem (I DID UPDATE python-sqlite IN THE CORRECT ORDER).
This is, thanks to yum's role in managing the complete installed set, a
systemic issue; the whole system needs to atomically go from one consistent
state to another, and portions of the system in one state need to be isolated
from those portions of the system in the other state. Otherwise there will
be problems; no, they are not terribly widespread; but the general case
solution would work wonders for yum updating its own 'stuff' too.
In the general case, I'd like to issue something like:
# acidfs-begin-transaction
# yum -y update
[bunch of output]
# if yum-no-error-condition;
# acidfs-commit
# else
# acidfs-rollback
# fi
RDBMS's have been doing this for decades. I do this daily, using SQL. Note
that, for all processes except the shell process inside the transaction, no
changes have occurred to the filesystem; after acidfs-commit all the
changes 'suddenly' appear (and hopefully in-core text is reloaded if
possible); if you get to acidfs-rollback, everything reverts and no process
is any the wiser.
> Yum is managing the
> whole system.
It is currently managing the whole filesystem. But what about in-memory
program text? The currently loaded programs need to continue to have the
older libs available if needed; a single 'commit' operation at the end needs
to atomically reload program text and provide consistent library dependencies
post-run (the only way you can do this now is shut down the system, boot
rescue media, and yum update to a chroot (which is the system), then reboot
the system (aka 'booting an update CD'; anaconda does this quite well)). The
in core text needs to be isolated from what's going on on the filesystem, and
if an error occurs (out of space, for instance, or a locked file) an atomic
rollback would be very nice (anaconda does not do this, though).
> Given an ACID database, would you expect to be
> able to upgrade it to a new, potentially incompatible version of
> an ACID database with transactions in progress?
Of course I would; a filesystem/database (hmm, let's see, similar to, but
farther beyond what NILFS claims) would have to be guaranteed backwards
compatible. That's a given for a filesystem; it is unreasonable for the
authors of a filesystem to introduce such changes and expect seamless updates
of the filesystem code itself.
> What yum needs
> is just some special consideration when modifying its own
> components.
Ok, let me repeat: I updated the yum components in the right order. This is
NOT the sqlite/python-sqlite issue. In my case, after following the advice
of updating python-sqlite, then sqlite, then yum and its dependencies, I got
a system with a lot of dupes and out of sync libraries. Lots of out of sync
libraries; I've not finished the recovery yet, although bind at least is
working. If there were a 'yum rollback' (or a 'acidfsrollback
snapshot-prior-to-yum') then I could at least try it again. But there isn't,
and I know there isn't, and I know all the deal about no support, etc etc.
But, yes, yum does need some special care with its own components; but that's
the narrow view; I'm looking at the big picture of a possible system-wide
rollback/commit facility for true systemic atomicity; consistency of the
in-core text versus on-disk text (the times I've tried to open something
with, say, firefox, when it has been open for a while, but after it has been
yum updated and the open fails in mysterious ways are rather annoying; this
is not unique to CentOS); isolation of the changes that are happening on-disk
and the view from the in-core text (my firefox example; if you run a yum
update of firefox while firefox is running, strange things are guaranteed to
happen to your running firefox as its in-core text becomes inconsistent with
the on-disk libs and such!); and durability of the change (once committed,
fully committed).
Yes, I know a reboot to special update media would fix all that; that's an
anaconda-mediated update, and from the system's point of view it is atomic
(you're just doing the update under general anesthesia, so to speak). But
online updating, and updating without rebooting, are things I am not really
willing to give up (especially when the quarterly update is as large as it is
usually; makes Windows XP Service Pack 2 look like you're downloading a small
text file!)
Just throwing an idea out, that's all, for discussion. This systemic
non-atomicity and inconsistency is endemic to all linuxen at the moment.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
