[449] in athena10
Re: Login chroot design for Athena 10
daemon@ATHENA.MIT.EDU (Greg Hudson)
Tue Aug 19 13:53:23 2008
From: Greg Hudson <ghudson@MIT.EDU>
To: Quentin Smith <quentin@mit.edu>
Cc: athena10@mit.edu
In-Reply-To: <Pine.LNX.4.64L.0808191343230.11949@vinegar-pot.mit.edu>
Content-Type: text/plain
Date: Tue, 19 Aug 2008 13:50:10 -0400
Message-Id: <1219168210.12433.274.camel@error-messages.mit.edu>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
On Tue, 2008-08-19 at 13:44 -0400, Quentin Smith wrote:
> > Can we reasonably expect to remount / without putting the system through
> > horrible trauma?
>
> I think remounting / is less likely to put the system through trauma than
> performing updates inside a chroot is...
Remounting / means every existing process suddenly sees a different
filesystem than it did before. I don't know what happens to currently
open files. That's pretty scary.
We perform updates inside chroots all the time on the build machines.
There's nothing intrinsically frightening about it.
Since we can't do snapshots of snapshots, it makes some sense to return
to Ken's design of snapshotting the root volume and chrooting into the
snapshot. But the architectural benefits for the update aren't as cut
and dried:
* Snapshot the root for the login chroot
* Start an update of the real root
* User logins in and logs out
* Update is still going. Do we:
- Snapshot it anyway, mid-update?
- Reuse the snapshot for the next login, instead of deleting it as
we normally would?
- Block logins until the update completes?
