On 11/15/13, 7:42 PM, Paul B. Henson wrote: >> From: Saso Kiselkov [mailto:[email protected]] >> Sent: Friday, November 15, 2013 8:51 AM >> >> It should run fine on bloody (and perhaps even on stable, but I'm not >> super-confident in that). > > Hmm, if it's not intended for stable, it's probably not a good test to try > and use it there. If it blows up or does weird things, there'd be no way to > tell if it was an underlying issue or simply an incompatibility with the > older code base. The box isn't quite in production yet, I'll update the new > boot environment to bloody, pound on it for a week or so and then roll back > to my stable. Although, the next stable should be out any day now, so if I > get lucky I'll just be able to set my publisher back to stable in the new BE > and not have to rollback.
The "not intended for stable" has more to do with interoperability with libzfs.so than anything else. The interconnection there is a little delicate. If you do encounter userland troubles (e.g. zfs(1M) not working properly), give me a ping, I'll build an up-to-date libzfs.so for you. >> I'd appreciate it if you can), make sure your dump device is set to a >> physical partition or device, NOT a zvol, since a crash in the ZFS >> module precludes any dump to a zvol. That having been said, I don't >> expect any crashes (haven't had any myself). > > My dump device is currently a raw disk partition. Any thoughts on a good > test methodology? Also, if I recall correctly I need to remove and then > re-add the cache devices in order to enable persistency? Just use it as normal and do the occasional reboot, watching for correct rebuild (i.e. most of your L2 cache contents should get recovered). No need to re-add your device, it should get picked up automatically. Cheers, -- Saso _______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
