On Mon, Feb 02, 2009 at 02:56:49PM -0600, Shawn Walker wrote: > Brock Pytlik wrote: > > I'm sure you've thought of this, but why not leverage ZFS for all this? > > You could have the depot always serving from a read-only zfs snapshot > > (clone?). When you're publishing, you publish to the > > current/live/writable file system, when you're done with the staged > > publishing (including generating the search indexes and feed cache if > > necessary), a zfs snap shot is taken (and a clone if necessary). The > > depot then repoints itself to serve out of the new snapshot/clone. > > > > Sorry if I'm rehashing something you've already thought of and > > dismissed, it just seems strange to be reinventing a snap shotting > > mechanism, especially since I don't think we'll be able to duplicate the > > ondisk space savings of snapshots, which if you want to serve from > > arbitrary past snapshots, seem significant. > > You are correct that ZFS may be more efficient for a snapshot system. > However, there are some administrative and development tradeoffs that I > felt were too limiting: > > * Would require zfs for snapshot support. > > * Would require that either the repository directory of the repository > "metasets" be a zfs filesystem. > > * Is significantly more complex to implement. > > * Would require that the depot software run with the privileges > necessary to create and/or destroy filesystems or snapshots. > > * Assuming the the entire repository directory is represented by a > snapshot, that would pre-clude the ability to have a file/ directory > with files for packages newer than that being served by the current > snapshot/metaset. > > The basic idea here is that the repository metadata is essentially split > during publishing; it publishes to one and serves the other until a > "commit" is done. This allows a single depot server to handle both > requesting and publishing clients.
There seems to be some confusion about the purpose of this proposed change. When Dan and I discussed this, it was to solve a distributed consistency problem with rolling out new builds on a load-balanced group of depots. When performing a rollout, Dan saw that some depots restarted faster than others. Since there's no session persistence in the load-balancer, clients can be routed to a different depot for every request. In some cases, a client would get the catalog from an updated depot, but would be unable to fetch a manifest, or files. The subsequent request was hitting a depot that was still out of date. We're still going to use ZFS snapshots to move the depot's data around, since it simplifies administrative tasks. The changes to the depot software are to allow a rollout of a build to appear consistent in a distributed environment. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
