Hi, You never experienced any faulted drives, or something similar? So far i only saw imbalance if the vdevs add changed, if a hotspare is used and i think even during a replacement of one disk of a raidz2 group. I
Bruno On 25-3-2010 9:46, Ian Collins wrote: > On 03/25/10 09:32 PM, Bruno Sousa wrote: >> On 24-3-2010 22:29, Ian Collins wrote: >> >>> On 02/28/10 08:09 PM, Ian Collins wrote: >>> >>>> I was running zpool iostat on a pool comprising a stripe of raidz2 >>>> vdevs that appears to be writing slowly and I notice a considerable >>>> imbalance of both free space and write operations. The pool is >>>> currently feeding a tape backup while receiving a large filesystem. >>>> >>>> Is this imbalance normal? I would expect a more even distribution as >>>> the poll configuration hasn't been changed since creation. >>>> >>>> The system is running Solaris 10 update 7. >>>> >>>> capacity operations bandwidth >>>> pool used avail read write read write >>>> ------------ ----- ----- ----- ----- ----- ----- >>>> tank 15.9T 2.19T 87 119 2.34M 1.88M >>>> raidz2 2.90T 740G 24 27 762K 95.5K >>>> raidz2 3.59T 37.8G 20 0 546K 0 >>>> raidz2 3.58T 44.1G 27 0 1.01M 0 >>>> raidz2 3.05T 587G 7 47 24.9K 1.07M >>>> raidz2 2.81T 835G 8 45 30.9K 733K >>>> ------------ ----- ----- ----- ----- ----- ----- >>>> >>>> >>> This system has since been upgraded, but the imbalance in getting >>> worse: >>> >>> zpool iostat -v tank | grep raid >>> raidz2 3.60T 28.5G 166 41 6.97M 764K >>> raidz2 3.59T 33.3G 170 35 7.35M 709K >>> raidz2 3.60T 26.1G 173 35 7.36M 658K >>> raidz2 1.69T 1.93T 129 46 6.70M 610K >>> raidz2 2.25T 1.38T 124 54 5.77M 967K >>> >>> Is there any way to determine how this is happening? >>> >>> I may have to resort to destroying and recreating some large >>> filesystems, but there's no way to determine which ones to target.. >> Hi, >> >> As far as i know this is a "normal" behaviour in ZFS... >> So what we need is somesort of "rebalance" task what moves data around >> multiple vdevs in order to achieve the best performance possible... >> Take a look to >> http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6855425 >> >> > It would be if drives had been added, but this pool hasn't been > changed since it was created. >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss