snapraid + adding new drive

  • not sure where exactly i can prevent drives to go to sleep, is it good idea performance wise?

    Having drives sleep is not a default behavior. If it's happening, you did something to cause it.


    I can understand the desire to save power, but the interface latency introduced by having drives go into sleep mode is unacceptable to me. Going in and out of sleep mode is also harder on drives than leaving them spun up.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

    • Offizieller Beitrag

    but i dont know whats actuall setup ... this is how it looks like and i think drives go to sleep ;/

    Are you using HC1 or HC2? You can set the spin down time by the firmware for the USB to SATA controller. You can also disable spin down.
    https://wiki.odroid.com/odroid-xu4/software/jms578_fw_update

  • @macom not sure ;/
    root@openmediavault:~# dmesg | grep -i jmicron
    [ 25.169349] usb 4-1.2: Manufacturer: JMicron
    [ 25.196647] scsi 1:0:0:0: Direct-Access JMicron Generic DISK00 0103 PQ: 0 ANSI: 6
    [ 25.242911] scsi 1:0:0:1: Direct-Access JMicron Generic DISK01 0103 PQ: 0 ANSI: 6
    [ 25.305530] scsi 1:0:0:2: Direct-Access JMicron Generic DISK02 0103 PQ: 0 ANSI: 6
    [ 25.390773] scsi 1:0:0:3: Direct-Access JMicron Generic DISK03 0103 PQ: 0 ANSI: 6


    and also here is smarctl -t long of sdd
    http://paste.debian.net/1076164/

  • @macon what did u want to write in your last post?



    I execute while true ; do echo "foo" >> test.txt; sleep 60; done inside dir where /dev/sdd1 is mounted... and i am not getting any error posted before in dmesg since that time.


    Also if i do ls /export/storage results are immediately returned. So is it possible that data corruption is bc of external box where the drives are plugged? Ie happening as box - its controller go to sleep or somehow put drives into the sleep? no clue.

    Einmal editiert, zuletzt von lenovomi () aus folgendem Grund: mistakes

    • Offizieller Beitrag

    @macon what did u want to write in your last post?

    I was under the impression that you were not sure which hardware you are using. As you posted this (Linux openmediavault 4.9.61-odroidxu4) before I assume you are on either XU4, HC1 or HC2. That means the usb-to-sata controller is controlling your spin down time of the HDD and you can change the time or disable it via the firmware of the controller.

  • I was under the impression that you were not sure which hardware you are using. As you posted this (Linux openmediavault 4.9.61-odroidxu4) before I assume you are on either XU4, HC1 or HC2. That means the usb-to-sata controller is controlling your spin down time of the HDD and you can change the time or disable it via the firmware of the controller.

    @macom well i am not sure what is HC1 or HC2? I use odroid xu4, and usb box which contains Manufacturer: JMicron controller? But i dont know version of it?



    Is it possible that sleep was corrupting data? Since i executed that shell with touch ... i cant see any new issues in dmesg.


    So maybe the first step is to identify what is the JMicron version? After that to disable spin down on that controller? Is firmware upgrade required?


    thanks

  • Hi,
    as was suggested from the beginning ...


    1) i replaced the hw ... odroid to rpi4
    2) fresh new install of
    openmediavault 4.1.30-1


    After few days of running i got again into the dmesg following error:
    [122007.936115] EXT4-fs error (device sde1): htree_dirblock_to_tree:1023: inode #19808260: block 79176240: comm mergerfs: bad entry in directory: rec_len % 4 != 0 - offset=0, inode=3847175076, rec_len=35378, name_len=43, size=4096


    plus :>
    [171733.098887] sd 1:0:0:3: [sde] tag#13 uas_eh_abort_handler 0 uas-tag 14 inflight: CMD IN
    [171733.098906] sd 1:0:0:3: [sde] tag#13 CDB: opcode=0x88 88 00 00 00 00 00 00 00 29 78 00 00 00 08 00 00
    [171733.099125] sd 1:0:0:3: [sde] tag#7 uas_eh_abort_handler 0 uas-tag 13 inflight: CMD IN
    [171733.099138] sd 1:0:0:3: [sde] tag#7 CDB: opcode=0x88 88 00 00 00 00 00 00 00 29 70 00 00 00 08 00 00
    [171734.527362] usb 2-2: stat urb: no pending cmd for uas-tag 13
    [171761.899363] sd 1:0:0:0: [sdb] tag#8 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
    [171761.899381] sd 1:0:0:0: [sdb] tag#8 CDB: opcode=0x28 28 00 61 20 67 90 00 00 08 00
    [171761.939379] scsi host1: uas_eh_device_reset_handler start
    [171762.090240] usb 2-2: reset SuperSpeed Gen 1 USB device number 3 using xhci_hcd
    [171762.124950] scsi host1: uas_eh_device_reset_handler success
    [171762.125293] scsi host1: uas_eh_device_reset_handler start
    [171762.270243] usb 2-2: reset SuperSpeed Gen 1 USB device number 3 using xhci_hcd
    [171762.304941] scsi host1: uas_eh_device_reset_handler success


    What should i do now? Run fsck / smartct on that sde1 drive? The drive is inside box for 4 drives... which is connected via usb3 to RPI4.


    Thanks!

  • Don't know if those are related given the time difference between them but certainly could be. USB3 - SATA controllers are not known for being the most stable and it's totally possible that the drive is fine and the controller is flaky. Does this happen often enough that if you put the drive in another enclosure you'd expect to reproduce this in a short time?


    Also ensure your Pi power supply and cable are up to spec. I'm less familiar with the 4 but previous versions could behave poorly the power was not delivered up to spec.

  • Don't know if those are related given the time difference between them but certainly could be. USB3 - SATA controllers are not known for being the most stable and it's totally possible that the drive is fine and the controller is flaky. Does this happen often enough that if you put the drive in another enclosure you'd expect to reproduce this in a short time?


    Also ensure your Pi power supply and cable are up to spec. I'm less familiar with the 4 but previous versions could behave poorly the power was not delivered up to spec.

    Hi,
    its all the same issue as reported at the beginning of that thread.


    I do not have other controller / way to test drive itself...


    Yes - Pi is with original cables/ charger with enough power (+Ampers).




    So no way how to find out the issue?

  • I don't see how without a way to narrow down what the issue is. Clearly the USB device being reset isn't a good sign. It could be bad controller, bad usb cable, bad drive. To find out which you need to be able to swap each out.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!