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. > 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. 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. -- Alan DuBoff - Solaris x86 Engineering - IHV/OEM Group Advocate of insourcing at Sun - hire people that care about our company!
