Alan DuBoff wrote: > On Monday 29 January 2007 03:30 pm, Dave Miner wrote: >> The devil, of course, is in the details, and there are a lot of them >> here. Heck, while working on updating the Live Media project code to >> work with snv_55 I just found over the weekend that Gnome 2.16's trying >> to write font caches into a bunch of paths under /usr after initial boot >> (and doesn't work at all without it), which I don't believe even works >> with our read-only /usr for diskless clients. God knows the Live Media >> project would be a lot easier if we already had this ;-) > > Dave, > > The way I think about this, Gnome would still be able to update /usr, given > root access, just that it would be laid over the top of what was a read-only > FS. A user might still need to change a file/binary, sendmail being the > classic example I 'spose. > > In this scenario, you would always be guaranteed to have a clean bootable > filesystem, since it is treated as a ROM. Only that it can actually be > updated. > > I suspect this wouldn't be a simple project, it would take some thought. >
No question about that. I'm pretty lukewarm on this sort of UnionFS approach, though; it seems to add layers of complication and cost without a counterbalancing level of improvement. And I'm really unclear on how well such an approach would interact with our desire to move decisively to ZFS as our primary file system and leverage snapshots and clones for the operations which they obviously would benefit. >> I'm guessing that Caiman may propose some amounts of change to the >> system layout to make upgrades and so on easier and faster; we haven't >> gone far enough down the road yet to suggest what they might be, but I >> wasn't necessarily thinking we'd want to bite off the whole read-only >> installation thing. I wouldn't discourage it, but depending on it seems >> unnecessary. > > It's certainly a risk, IMO. However, nobody ever made great gains by not > taking risk. It might be something for a follow-up, you're more intimate with > the project than myself. > Caiman's got risk flowing out of its nostrils already ;-) > Some things will change with zfs root in itself. Will we have filesystems for > /home, /opt, /var, /usr, /etc, even /export, or will those remain as > traditional directories? I hope those are filesystems in themself. Ultimately > they will end up being filesystems, IMO. > I don't know yet, but there are some cases where it would obviously be beneficial to go to separate file systems, such as some of the areas under /var which might be shared between instances of the OS, or /etc which could benefit from frequent snapshots for change management. My initial idea is that we design Caiman to deal with an arbitrary breakdown of file systems and let the specifics sort themselves out as time goes on;. We have a component which has to put together the installable file system layout and present it to the installer as a complete directory hierarchy mounted somewhere, so the complication involved is relatively isolated and small, especially if we're not having to create slices in a VTOC for every one of them. Dave
