R.G. Keen wrote: > I didn't see "remove a simple device" anywhere in there. > > Is it: > too hard to even contemplate doing, > or > too silly a thing to do to even consider letting that happen > or > too stupid a question to even consider > or > too easy and straightforward to do the procedure I see recommended (export > the whole pool, destroy the pool, remove the device, remake the pool, then > reimport the pool) to even bother with? > It is too complicated to implement directly.
As with lvm2 and comparable technologies, one would have to first have a feature that moves all extents from one physical volume to the other available phys.-vols. Then, when allocating the replacement blocks, the algorithm could quickly become _very_ unwieldy, because the pool will still have to keep it's redundancy guarantees [1]. As you can imagine this can be very complex with ZFS mixture of raid, parity, _dynamic_ striping (simply realllocating the blocks could cause massively fragmented disks if the pool/vdev previoiusly used dynamic striping). Using 'copies=n' and extra parity (raidz2,raidz3) further complicates the matter. In all circumstances about the only algorithm to specify for the transformation _with_ the guarantee that all invariants are (logically[2]) checked is to use the wellknown send/recv kludge. In that case you'll simply need double the storage and a lot of processing resources to make the transform. There are a number of situations in which the logic can safely be simplified (using only dynamic striping and using only full disks and when there is a 'third' (recent disk) not involved in any of the existing stripes to receive the relocated stripes.... etc. In effect, I doubt that these situations are ever going to cover more than what 'detach' and 'replace' offer at this moment in time. So, in a word, yes this is (very) complicated. The complicating thing is that ZFS does dynamic striping and RAID redundancy properties _automagically_. This dynamicity make it very hard to define what needs to happen when a disk is removed (likewise for replacing with a smaller disk). 'Static' RAID tools have the advantage here, because they can guarantee how stripes are layout across a 'pool', and also because the admin can limit the options used for a pool precisely to enable 'special operations' like 'remove physdev'. However, even if so, removal off a disk (as opposed to replacement) is a very uncommon use case for any RAID solution that I know of. [1] of course, you could replace that complexity by a burden on the user: let removal of a drive have the same effect as physically failing that device, degrading the pool. Then you would have to either replace the vdev or re-add a vdev to restore the redundancy. [2] by which I mean, barring bugs in, say, send/recv _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
