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.
How LiveJournal is sticky
Given the recent commotion over some of LiveJournal's business decisions and people's unhappyness with LiveJournal as a result, I've been thinking about the various ways that LiveJournal makes itself sticky (and thus hard to leave, and so on). I think that there are three general levels of LiveJournal stickyness, in ascending order:
- the simplicity and ease of use for individual users.
- the network effects: the more that people that you want to read use
LiveJournal, the more attractive it is to be there and read them in
(At least in the beginning this combined strongly with the ease of use issue and I think that it continues to some degree even today, despite things like Google Reader.)
- what I will call social stickiness, which are all of the LiveJournal
features that enable communities to spring up; these are things
like comments with attached user identities and private (locked)
(Actual LiveJournal communities are useful, but I think not as important as the core social-enabling features that let you associate with identifiable people.)
I think that a lot of discussion about how people can (or can't) just migrate away from LiveJournal miss the incredible stickiness of the last level. Given that people are social, enabling that sociability is a very serious attraction.
These days, blogs can be user friendly (and there have always been places that let you easily create a blog of your own) and syndication feed readers and aggregators can lower the network effect, but I don't think that there's anything that can substitute for the third level. It's hard to see how there could be in the near future, because there are a horde of hard problems to be solved (starting with automatic cross-site identities that work through your syndication feed reader).
(Communities form even without these enabling features; I would be remiss if I didn't mention the anime blogging community as one example. But I think that the social features that LiveJournal has make it much easier to have communities form and stay, and to make it so that new people can more easily get pulled into them.)