On Thu, Oct 22, 2009 at 9:46 AM, Allen Eastwood <mi...@paconet.us> wrote: > A while back I posted about using the combination of ZFS roots and > Live Upgrade when patching. I've made that my default patching > strategy and in doing so have avoided the last few major issues that > have come up with patches, including this one.
That's the beauty of Live Upgrade. When it doesn't break. > My ZFS root pools do not have /var on a separate dataset. do you mean a separate file system, or do you mean in a different pool? > Even if you are on UFS root still, you can use Live Upgrade...it takes > longer, but patching an ABE on an alternate mount point seems to be > MUCH safer. I've applied this, and the last few kernel patches on > multiple sparc, CMT and x86 systems completely without incident. Agreed. I have regularly used multiple 20G / with ABE space for 8, 9 and 10 (pre-zfs) for this exact purpose. Depending on the size of the physical disk (and I was almost always mirroring with SDS) was the determining factor for sizing. for 300G disk, I leaned towards 30-40G, depending on how the system resources were to be used. I'm real crazy about not having a separate /var, but the recoverabilty far outweighs the issue for me about having /var on a / slice. Real monitoring of disk space (along with notification) mitigates space issues that might arise from something running away with /var space.
