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. Shawn Walker wrote: > Brock Pytlik wrote: >> Shawn Walker wrote: >>> There is a major flaw here that just came to mind; notably, that the >>> catalog, index, and updatelog directory all have to be included as >>> part of this. In other words, if I'm serving a particular version >>> of a catalog, then I also have to serve a corresponding version of >>> the search index and updatelog. >>> >> Because the search index is already being built in an alternate >> location then moved into place when it's able to, it would be a >> fairly simple change to alter this behavior to not replace the >> current search index until actually told to. > > Since I need the ability to serve any previous snapshot, I'd also need > to snapshot the search data, etc. One copy of the search data alone > wouldn't suffice, unless I'm misunderstanding you. Oh, didn't know you wanted to be able to do any previous snapshot. > Brock _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
