Wandering Thoughts archives

My wishes for Sun's online documentation

I have some wishes for docs.sun.com, Sun's theoretically helpful collection of online documentation.

Sun has a lot of documentation about how to do things with Solaris. Well, how to do things with specific versions of Solaris, for example one for each specific release of Solaris 10. This level of archived documentation for each specific release is commendable, but it leads directly to my first wish:

I wish that Sun had permanent URLs that were always the current versions of any particular document; I would be happy if this was merely 'for Solaris 10', so you had a URL for the current 'Solaris 10 system administration guide' and the like. This URL should be a real document, not merely a redirection, because my goal is to get people to stop bookmarking and linking to release-specific documentation. All of the top level indexes and pages should point first to these current documentation URLs, of course.

(Older versions should be accessible, but through different URLs and ideally with URLS and labels that make it very clear that they are not the documentation for the current Solaris release. Bonus points are awarded for cross linking versions, so that if you actually want the version of a particular document for Solaris 10 update 4, it's easy to jump from the current version to that version.)

Once this is done, my next wish is that Sun's docs.sun.com search engine would automatically exclude release-specific documentation in favour of the current documentation any time that the current documentation matches all of the search terms. If this is too radical, it should show the older versions in the same way that Google shows closely related search results and give primacy to the current version.

(Of course, if you are searching within the documentation for a specific release, the search engine should still restrict the search results appropriately.)

These wishes are brought to you by someone who is tired of old and now obsolete versions of Solaris documentation turning up in various sorts of searches. Especially when he settles in to read some of them for a while before noticing that they are in fact obsolete.

(While I'm wishing for the impossible, I'd like docs.sun.com to have a site design and URL scheme that is vaguely modern (in a good way; their current URL scheme is arguably modern in a bad way).)

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.

• refquota doesn'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 imports.

  (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 failmode setting 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 userquota. This would be an inherited quota (unlike refquota) that applied only to 'things that normal users can delete' (unlike quota, which 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.

The ufsdump block size doesn't seem to matter much

Some time ago I discovered that the Linux dump block size can make a significant performance difference. Ever since then I had in the back of my mind to find out if the same thing was true on other systems, with other versions of dump, and recently I got around to doing some experimentation on Solaris.

In the spirit of sharing negative results as well as positive ones: no, it doesn't seem to. I got a modest performance increase by specifying a b value greater than the default of 64 (32kb), with the best numbers seeming to happen around a b value of 256 (128 Kb). But at best this amounted to only a few megabytes a second, hardly the drastic improvements seen on Linux.

(The other way to look at the Linux numbers is to say that it performs terribly by default, while Solaris performs decently by default.)

Now, it's hard to be definitive about this (proving a negative is always challenging), since there could be any number of reasons that my testing had unusually slow results. However, I'm confidant enough that the results are applicable to real filesystems that I care about that I'm not going to bother with more testing.

(I did testing on both Solaris 8 SPARC and Solaris 10 x86 (64-bit), in both cases using filesystems on mirrored DiskSuite metadevices, and at least on the Solaris 10 system ufsdump's performance was well under the read speed of the raw metadevice.)