2007-06-25
ZFS's issues with long term storage management
Unfortunately, one of ZFS's current issues is that it does not have any direct support for the sort of data migration you need to do for long term storage management. There are three possible approaches to this:
- direct migration support: not present.
- growing a pool with the new storage then shrinking it by removing the old storage: while ZFS can grow pools it can't shrink them.
- add the new storage as a mirror and then detach the old storage: you can't mirror raidz or raidz2 pools.
The way you are supposed to use ZFS is to feed it raw disks and make raidz or raidz2 pools with them, but this leaves you without good migration options. Replacing individual disks as if they had failed and been replaced is not good enough; it takes out your redundancy for the duration of the rebuild, plus you can never change the number of disks that the storage pool is using.
If you let your backend handle the RAID bits and feed ZFS logical disks instead of physical ones, you can fake migration through mirroring (since you can mirror and then unmirror disks that are not part of a raidz or raidz2 pool). But doing this gives up some of ZFS's performance and reliability advantages and you don't get RAID 6 unless your backend supports it, which not all do.
(Shrinking ZFS pools is theoretically a planned future feature, but I can't make plans that count on it until it actually gets implemented and appears in Solaris.)
2007-06-01
Why our Solaris fileservers still use the automounter
In theory, there's no need for your fileservers to use the automounter.
Even if you make the filesystems visible under their normal names as
well as in /export, you could mount them explicitly in /etc/vfstab.
However, doing so would significantly complicate our environment,
because it turns out that the automounter worries about a number of
issues for us.
Of course, one big reason to use the automounter is administrative convenience; you can use the same set of automounter maps on your fileservers as you do everywhere else, instead of having to build special ones and keeping the same information in at least two different places. (Whether fileservers should ever have NFS mounts is another question, but our local environment forces the issue and requires it.)
We have an additional complication, because for failover our NFS fileservers are virtual. This means that which physical machine owns a filesystem and thus needs to loopback mount it can change on the fly. It turns out that the Solaris automounter is smart enough to deal with this without any configuration changes and without us doing anything extra at failover time.
(I assume that it is noticing that the IP address it is trying to NFS mount from is one of the IP addresses associated with the current machine, even though the host name of the NFS server is not the machine's hostname.)
Using static mounts in this situation isn't impossible, but it'd be another thing we'd have to build into the failover startup stuff. The automounter conveniently handles it all for us.
(This entry was sparked by a comment on a recent entry.)