Mike,
This RFE is still being worked and I have no ETA on completion...
cs
Mike Seda wrote:
I noticed that there is still an open bug regarding removing devices
from a zpool:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4852783
Does anyone know if or when this feature will be implemented?
Cindy Swearingen wrote:
Hi Mike,
Yes, outside of the hot-spares feature, you can detach, offline, and
replace existing devices in a pool, but you can't remove devices, yet.
This feature work is being tracked under this RFE:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4852783
Cindy
Mike Seda wrote:
Hi All,
From reading the docs, it seems that you can add devices
(non-spares) to a zpool, but you cannot take them away, right?
Best,
Mike
Victor Latushkin wrote:
Maybe something like the "slow" parameter of VxVM?
slow[=iodelay]
Reduces toe system performance impact of copy
operations. Such operations are usually per-
formed on small regions of the volume (nor-
mally from 16 kilobytes to 128 kilobytes).
This option inserts a delay between the
recovery of each such region . A specific
delay can be specified with iodelay as a
number of milliseconds; otherwise, a default
is chosen (normally 250 milliseconds).
For modern machines, which *should* be the design point, the channel
bandwidth is underutilized, so why not use it?
NB. At 4 128kByte iops per second, it would take 11 days and 8 hours
to resilver a single 500 GByte drive -- feeling lucky? In the bad old
days when disks were small, and the systems were slow, this made some
sense. The better approach is for the file system to do what it needs
to do as efficiently as possible, which is the current state of ZFS.
Well, we are trying to balance impact of resilvering on running
applications with a speed of resilvering.
I think that having an option to tell filesystem to postpone
full-throttle resilvering till some quieter period of time may help.
This may be combined with some throttling mechanism so during
quieter period resilvering is done with full speed, and during busy
period it may continue with reduced speed. Such arrangement may be
useful for customers with e.g. well-defined SLAs.
Wbr,
Victor
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
