Hi @grwilson, As a recall, the original problem that led to the patch is described here :
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204622 > These knobs expose the internals of the product. Yes, but I don't think exposing the internals of the product is a problem here because it does not make the command more complex : for the average user, its default action is still the same (invalidating all four labels). We just provide an administrator the possibility to go *beyond* and avoid the hassle of using dd plus a seek argument (this *is* a kind of simplification, but for the administrator) as @jpaetzel explains. > why wouldn't I just run zpool labelclear and have the command figure out if > we need to clear label 2 and 3 or 0-3 or any combination? I do not always want to let ZFS choose the labels for me because I may want to minimally invalidate them at the beginning of a device (to avoid issues described at the link above) and totally wipe (zeroe) them at the end (e.g. to produce a clean disk image). The current implementation simply does not provide enough flexibility for that. > I still struggle with invalidating the nvlist encoding vs setting txg = 0 > [...] I wonder if we ever need to "wipe" the labels or do we just want zfs to > forget about this device? As @jpaetzel wrote, I think we want to be able to do both. The default behaviour is to minimally invalidate labels, but an option is provided to wipe them entirely if one needs it. Regarding the idea of invalidating a label using its encoding style, you're right, touching 1 byte can break another FS too, but it's always better than modifying 8 bytes (and even better than what is done currently : zeroing 4 * 256 KiB). Also, as you noticed, debugging tools could be expanded to handle that kind of invalid encoding. Best regards, Ganael. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/openzfs/openzfs/pull/424#issuecomment-364754358 ------------------------------------------ openzfs-developer Archives: https://openzfs.topicbox.com/groups/developer/discussions/T59e810f5492df392-M83a3610d9da5a374f4d9e3c2 Powered by Topicbox: https://topicbox.com
