Hi Tom, everyone, Tom Mooney wrote: > A little extra info: > ZFS brings in a ZFS spare device the next time the pool is accessed, not > a raidbox hot spare. Resilvering starts automatically and increases disk > access times by about 30%. The first hour of estimated time left ( for > 5-6 TB pools ) is wildly inaccurate, but it starts to settle down after > that.
Thanks for your reply. I'm talking about zfs hot spares, not the hot spare functionality of the raid box: # zpool create -f data raidz c4t0d0 c4t0d1 c4t0d2 c4t0d3 c4t0d4 c4t0d5 c4t0d6 c4t0d7 c4t0d8 c4t0d9 spare c4t0d10 c4t0d11 I did my initial tests by pulling a disk during a 100GB sequential write, so that should have kicked in a hot spare right away. But no hot spare was activated (as shown by 'zpool status' and write performance fell to less than 25%. I have also tried to start resilvering manually, but that doesn't seem to work either. I've heard from several people that currently, zfs has problems with reporting the 'estimated time left' - but my issue is that not only the 'time left', but also the progress indicator itself varies wildly, and keeps resetting itself to 0%, not giving any indication that the resilvering will ever finish. And with nv-b76, 'zpool status' simply hangs when there is a drive missing, so I can't even really keep track of the resilvering, if any. So, at least for me, hot spare functionality in zfs seems completely broken. Any suggestions on how to further investigate / fix this would be very much welcomed. I'm trying to determine whether this is a zfs bug or one with the Transtec raidbox, and whether to file a bug with either Transtec (Promise) or zfs. Regards, Paul Boven. -- Paul Boven <[EMAIL PROTECTED]> +31 (0)521-596547 Unix/Linux/Networking specialist Joint Institute for VLBI in Europe - www.jive.nl VLBI - It's a fringe science _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
