Moinak Ghosh wrote: > Dave Miner wrote: >> Alan DuBoff wrote: >>> On Monday 29 January 2007 03:30 pm, Dave Miner wrote: >>>> [...] >>>> 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. > > Most of the UnionFS features like snapshots overlap with ZFS and ZFS > does a much > better job of handling those. The only benefit of using UnionFS would > be in the area > of Install/Live media where a minimal UnionFS port will suffice. > Compare a ramdisk > just 10-20MB in size vs the current 256+ Meg. >
Sure, I totally agree that it's useful there, at least as a workaround, though I think we could make an extremely viable solution without UnionFS were we to look at the system architecture with this usage model as a requirement. Dave
