Thru a sequence of good intentions, I find myself with a raidz'd
pool that has a failed drive that I can't replace.
We had a generous department donate a fully configured V440 for
use as our departmental server. Of course, I installed SX/b56
on it, created a pool with 3x 148Gb drives and made a dozen
filesystems on it. Life was good. ZFS is great!
One of the raidz pool drives failed. When I went to replace it,
I found that the V440's original 72Gb drives had been "upgraded"
to Dell 148Gb Fujitsu drives, and the Sun versions of those drives
(same model number...) had different firmware, and more importantly,
FEWER sectors! They were only 147.8 Gb! You know what they say
about a free lunch and too good to be true...
This meant that zpool replace <drive> faild because the
replacement drive is too small.
The question of the moment is "what to do?".
All I can think of is to
Attach/create a new pool that has enough space to
hold the existing content,
Copy the content from the old to new pools,
Destroy the old pool,
Recreate the old pool with the (slightly) smaller
size, and
copy the data back onto the pool.
Given that there are a bunch of filesystems in the pool, each
with some set of properties ..., what is the easiest way to
move the data and metadata back and forth without losing
anything, and without having to manually recreate the
metainfo/properties?
(adding to the 'shrink' RFE, if I replace a pool drive with
a smaller one, and the existing content is small enough
to fit on a shrunk/resized pool, the zpool replace command
should (after prompting) simply do the work. In this situation,
losing less than 10Mb of pool space to get a healthy raidz
configuration seems to be an easy tradeoff :-)
TIA,
-John
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
