My reaction to Solaris 10 update 6's ZFS changes
I've been talking about my wait for Solaris 10 update 6 for a while, because it promised improvements and bug fixes for various ZFS issues that had been giving me heartburn. Since it's been out for a while and we've actually put it into production on one server, it's about time I did a review on how its ZFS changes stack up.
refquotadoesn't actually solve our ZFS pool quota problem, but it was never going to; it turns out that I failed to read the documentation properly and it doesn't do what I thought it did (which was, not coincidentally, just what I wanted). The good news is that S10U6 solves the pool quota issue anyways as a bugfix.
- ZFS cachefiles do not work the way I want them to work, but they
can be bent into shape to speed up our really slow ZFS pool
(The problem with ZFS pool imports is that every time you import a pool, '
zpool import' slowly re-pokes every LUN you have to build up a mapping of what is where. What I'd like is a (slow) command that just built that mapping and saved it in a file which future imports could use. This is not what S10U6 ZFS cachefiles are.)
- the new ZFS
failmodesetting does not in any way fix our pool panic problem. In fact it is a completely broken option as implemented in S10U6, where Sun has managed the difficult feat of making all of the new options worse than the current situation.
(Yes, that's right: Sun has created options that are worse than panicing your fileserver.)
If this is all opaque, see the Solaris 10 update 6 release notes for background on these new ZFS changes and features.
Note that currently I have not tested how well the new host ownership of ZFS pools works, so I have no opinion on that. It's not a high priority, since even with the S10U6 ZFS features I still feel that easy failover will be too fragile to make me happy.
(We would need two S10U6 test machines in order to test it out, and so far we have only ever had one.)
Sidebar: what I would like out of ZFS quotas
The ZFS quota option that I would like is what I will call
This would be an inherited quota (unlike
refquota) that applied
only to 'things that normal users can delete' (unlike
applies to everything). Normally this would be
the main filesystem, not including any snapshots, thus dealing with
the snapshot quota issue; it would be extended to
snapshots if you had delegated snapshot permissions to users.