Gragorg

Members
  • Posts

    499
  • Joined

  • Last visited

Posts posted by Gragorg

  1. So when I did my parity check this month I had an issue with a drive connection resetting so it took longer than normal.  When i completed the parity check it send a notification (telegram) that said it took "1 day, 9 hr, 4 min, 14 sec".  In reality it took "1 day, 17 hr, 29 min, 10 sec" and I can see that clearly in the history.  Yesterday I went to address the drive that was resetting  connection but since I had a warm spare already in my machine I just used it to rebuild.  The rebuild notification reported "1 day, 17 hr, 29 min, 10 sec" was the completion time.  In reality it took "8 hr, 20 min, 35 sec" as it is clearly listed in the history.  It seems to be sending the previous time.  Is this a known bug?

  2. The requirement for an array device is going to be removed in a future release.  The ZFS zpool has higher performance but drives do not spin down.  The array allows you mix and match hard drive sizes and expand one drive at a time when needed.  It also spins down unused drives to save power but performance is limited to the performance of a single drive as data is not striped.  If you lose one drive your data is covered in both cases (array and raidz).  If you lose two drives the raidz pool you would lose your data while the array would only lose the two failed disks and all remaining data would be intact.  You can add a second parity to the array to have a two disk fault tolerance. 

  3. I would run an extended smart test on the disk.  CRC errors are usually a connection issue.  However if the Realocated sector count and  Reported uncorrect increase it could be a disk problem and I would change the disk.  I believe CRC errors are already corrected.

  4. 15 hours ago, JorgeB said:

    I believe this is normal if you use macvlan with bridging disabled, try ipvlan if it works for you.

    This seems to be the case for me I am using macvlan with bridging disabled.  What really threw my for a loop is my netgear RAXE 500 actually sees both them for the same ip while my old router did not.

  5. The drive with problem is Sdc which appears to be your parity drive.  There is no point finishing the rebuild of parity until you figure out the cause.  I'm no expert but if it was me I would stop the rebuild powerdown and replace/check power and sata cables to your parity drive including any splitter you have on that drive and try again.

  6. Any share you setup has primary and secondary storage as well as mover action.  So if you set the download share primary as cache and array as secondary with mover action cache-->array it wlll move the download files to the array from the cache.  Most use the "arr" dockers to move media files to the media folder when completed.  Some setup media folders as array only so when downloads are completed they are moved direct into the array.  In this case media is setup as primary as  array and secondary and mover action are left blank.  Some prefer the media share set to cache as primary and array as secondary with the mover action set cache-->array.  In this case files are usable by your media player right away but are protect by the array once the mover runs.

  7. That CPU does not have quicksync so the CPU will get hammered trying to transcode with the cpu.  You could look for a used Xeon chip from the Haswell family that has quicksync built in.  A Haswell Xeon with quicksync will handle 1080p streams with transcoding all day long.  Here are E3 1275 v3 on ebay.  Worth mentioning I beleive you need plex pass to use hardware transcoding.