When ZFS code imports are brought forward that add feature flags there is a potential time bomb for existing users in that creation of a new pool becomes non-revertible (except read-only!) with regard to mounting on older revisions of the code. The same thing happens if you do a "zpool upgrade" of course, but at least that's an explicit act. You might not realize that you're at risk on a pool create, however, unless you **carefully** scrutinize the flags that were on the last version compared against the current one. The primary "gotcha" here occurs if you don't upgrade your emergency boot media and for some reason you need to boot from a CD or USB key -- you can be left SEVERELY screwed, and since -RELEASE is typically not rebuilt when this happens if you don't have a second machine laying around on which you can build a RELEASE image.... I've caught this twice now since 10.0-RELEASE shipped and, while I haven't been bit by it, it serves as a caution because eventually someone tracking -STABLE is going to get badly hurt and be left with an unrepairable system. IMHO there should be some sort of notice on the list when new zpool feature flags show up so you're fairly warned that building a new emergency boot media copy is required if you intend to track -STABLE on a continuing basis. -- -- Karl karl at denninger.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2711 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20140323/54313440/attachment-0001.bin>
On 03/23/2014 13:50, Karl Denninger wrote:> When ZFS code imports are brought forward that add feature flags there > is a potential time bomb for existing users in that creation of a new > pool becomes non-revertible (except read-only!) with regard to mounting > on older revisions of the code. > > The same thing happens if you do a "zpool upgrade" of course, but at > least that's an explicit act. You might not realize that you're at risk > on a pool create, however, unless you **carefully** scrutinize the flags > that were on the last version compared against the current one. > > The primary "gotcha" here occurs if you don't upgrade your emergency > boot media and for some reason you need to boot from a CD or USB key -- > you can be left SEVERELY screwed, and since -RELEASE is typically not > rebuilt when this happens if you don't have a second machine laying > around on which you can build a RELEASE image.... > > I've caught this twice now since 10.0-RELEASE shipped and, while I > haven't been bit by it, it serves as a caution because eventually > someone tracking -STABLE is going to get badly hurt and be left with an > unrepairable system. IMHO there should be some sort of notice on the > list when new zpool feature flags show up so you're fairly warned that > building a new emergency boot media copy is required if you intend to > track -STABLE on a continuing basis. >I understand your point, but you can also get snapshot isos built pretty regulary, so there should be no need to build your own in an emergency: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/ If weekly is not good enough, you can get daily: https://pub.allbsd.org/FreeBSD-snapshots/
Dne 23.3.2014 18:50, Karl Denninger napsal(a):> When ZFS code imports are brought forward that add feature flags there > is a potential time bomb for existing users in that creation of a new > pool becomes non-revertible (except read-only!) with regard to mounting > on older revisions of the code. > > The same thing happens if you do a "zpool upgrade" of course, but at > least that's an explicit act. You might not realize that you're at risk > on a pool create, however, unless you **carefully** scrutinize the flags > that were on the last version compared against the current one. > > The primary "gotcha" here occurs if you don't upgrade your emergency > boot media and for some reason you need to boot from a CD or USB key -- > you can be left SEVERELY screwed, and since -RELEASE is typically not > rebuilt when this happens if you don't have a second machine laying > around on which you can build a RELEASE image.... > > I've caught this twice now since 10.0-RELEASE shipped and, while I > haven't been bit by it, it serves as a caution because eventually > someone tracking -STABLE is going to get badly hurt and be left with an > unrepairable system. IMHO there should be some sort of notice on the > list when new zpool feature flags show up so you're fairly warned that > building a new emergency boot media copy is required if you intend to > track -STABLE on a continuing basis. >Excellent candidate for the /usr/src/UPDATING file? -- Ondra Knezour