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. Cheers, -- Shawn Walker _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
