https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290156
--- Comment #2 from Paul Telles (Starcat) <[email protected]> --- My apologies, I didn't realize that the gpart error wasn't fatal and jumped the gun because I had never received the 'CACHE PAGE TOO SHORT' errors in prior releases. I ran additional test(s) below and everything appears to be fine. Is there a known cause for the errors or are they benign? On a side note, is there anything that can be done to improve write performance? 66 MB/s is slow as compared to 114 MB/s with Fedora using the megaraid_sas driver. Thank you for your assistance. I greatly appreciate it and promise to troubleshoot things more thoroughly in the future. Kind regards, --Paul Additional test(s): # zpool create testpool raidz da0 da1 da2 invalid vdev specification use '-f' to override the following errors: /dev/da0 is part of potentially active pool 'scsitarg' /dev/da1 is part of potentially active pool 'scsitarg' /dev/da2 is part of potentially active pool 'scsitarg' # zpool labelclear -f da0 # zpool labelclear -f da1 # zpool labelclear -f da2 # zpool create testpool raidz da0 da1 da2 # zfs list NAME USED AVAIL REFER MOUNTPOINT testpool 147K 1.75T 30.6K /testpool # diskinfo -v /dev/da3 /dev/da3 512 # sectorsize 1000204886016 # mediasize in bytes (932G) 1953525168 # mediasize in sectors 0 # stripesize 0 # stripeoffset 121601 # Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. SEAGATE ST31000424SS # Disk descr. 9WK0YH4Y0000C0417UFB # Disk ident. mrsas0 # Attachment No # TRIM/UNMAP support 7200 # Rotation rate in RPM Not_Zoned # Zone Mode # dd if=/dev/zero of=/dev/da3 bs=1M count=1000 conv=fdatasync 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 15.838559 secs (66204004 bytes/sec) # -- You are receiving this mail because: You are the assignee for the bug.
