Date: Wed, 27 Feb 2013 17:09:02 -0800 From: Xin Li <delphij@delphij.net> To: Glen Barber <gjb@FreeBSD.org> Cc: freebsd-current@freebsd.org, d@delphij.net, Martin Matuska <mm@freebsd.org> Subject: Re: ZFS problems Message-ID: <512EAE2E.9010903@delphij.net> In-Reply-To: <20130228004404.GF82833@glenbarber.us> References: <1953411.keAzGZcpTL@zeus> <46832A2E33D240EABA0FBCF5F9C404C2@multiplay.co.uk> <CAGfVqw--ym78pdtzFfTWsS-L67vguPdASR4Kw=Wt82Sh-7SeVg@mail.gmail.com> <9083248.zOq17M83H4@zeus> <20130228003346.GE82833@glenbarber.us> <512EA6DB.3040502@delphij.net> <20130228004404.GF82833@glenbarber.us>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 02/27/13 16:44, Glen Barber wrote:
> On Wed, Feb 27, 2013 at 04:37:47PM -0800, Xin Li wrote:
>>> In mid-February, zpool version was upgraded to include
>>> lz4_compress. My understanding was that changing from the
>>> OpenSolaris ZFS version number scheme (i.e., "v28") to what we
>>> have on -CURRENT (i.e., "5000") was so that we can track
>>> crossing the point of no return with pool version upgrades.
>>>
>>> On my system, vfs.zfs.version.spa has been at 5000 since this
>>> original change.
>>>
>>> Is my understanding incorrect? Or should vfs.zfs.version.spa
>>> be incremented with major, non-backwards-compatible changes?
>>
>> That's incorrect. In theory vfs.zfs.version.spa will never ever
>> change in the future, and all new features will be denoted by
>> feature flags, which is an extensible way of representing
>> features and whether they are compatible with the running
>> system.
>>
>
> Thank you for clarifying.
>
> As there does not seem to be a specific sysctl that we can look
> for, I am inclined to say there should be UPDATING entries for such
> changes to note (at least for now) that 'make -C /usr/src/cddl
> install' can help prevent foot shooting.
Grrr I should have noticed this when doing code review for the change.
No, this is not intentional and has to be fixed, the issue was
introduced in r247265 ("deadman" feature).
Martin actually have done very good job maintaining ioctl
compatibility when we jumped from v15 to v28 that most people didn't
even notice that the ioctl was changed.
Cheers,
- --
Xin LI <delphij@delphij.net> https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCgAGBQJRLq4uAAoJEG80Jeu8UPuzlKAIAKPpCInGW6cIUXrrVkY11xMW
IK49TAUrxbBECpgo86gNtUZjWt7ik7nYRjxvocR4qKK5yM35fKsAInEN6LOYLCJm
ho4AIUex40sDr3K7avKMzi09Flsb3LfVtOYeAiZNk+oTPWRMj4vnw+VGxDMUq4/2
MXnaOpwI1mWDqnyBvtqspYh6dcUrqTX5+WrmucYuMgVHa7jsmJkorfhDp2ZBDjaM
afbvuVxcWV0aCajg44EHfKwQxTKGSNPIs7x3BTxBkao+TVuT1KJHbebF4EapNhe9
7jwM6XJhnSKIgXYgy8hpUPZB81mvxtvLuimTXi7c2rA9vs7sFu05wXgjbmKNLyQ=
=hW3e
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?512EAE2E.9010903>