Hot answers tagged

5

My general rule of thumb is that if the errors are continuing to rise unexpectedly, the disk needs replaced; if it's static, there might have been some transient condition that caused the error, and the system's not reproducing the conditions that caused problems. A few checksum errors doesn't necessarily indicate anything bad mechanically with the drive (...


3

I haven't tested it, but I have seen in other posts that you can remove all snapshots like this: zfs destroy -rv dataset_or_vol_name@% You could then follow-up with your destroy command to remove the database.


3

The general advice for this is to maximize your system RAM (ARC), and then add L2ARC if the need is there. This can be measured using the arcstat command in your server. Something like: arcstat.py -f "time,read,hit%,hits,miss%,miss,arcsz,c" 1 Where the output shows the time number of reads/second, the hit ratio, the number of hits/misses, and the ...


3

Having those errors across multiple drives seems to indicate a backplane/controller/cabling problem more than a disk or RAM issue.


2

Yes, it is. If you are unclear about such things in the future, just test them out with small files on your old pool first. You can create pools from regular files as long as their size is at least 64MB. The commands are the same, just give it the full paths of the files instead of the device paths. On Solaris this would be: # create your test files cd /...


2

Your pool black currently consists of two mirrored WD10JFCX drives, which according to Western Digital's spec sheet are: 5400 rpm (rotational latency about 5 ms on average, 11 ms worst case) 16 MB cache 1 TB 2.5" form factor SATA 6 Gb/s (SATA 3) Neither the 5400 rpm rotation speed nor the puny 16 MB on-drive cache is conducive to highest performance, and ...


1

This isn't a one liner, but you could use the output from zfs list -t all -r -H <dataset> And have a script go through it and verify things carefully and destroy the the appropriate filesystems.


1

People generally speak about bit rot in regards to RAID rebuilds, as it is the worst time to encounter a unrecoverable read error. Issues with rebuilds can generally be boiled down to 3 areas. hardware failure (during a rebuild), user error, and poor maintenance. I have seen lots of users try to "recover" a RAID volume, and just make things worse for ...



Only top voted, non community-wiki answers of a minimum length are eligible