Jump to content

Alexander Eiblinger

Members
  • Posts

    16
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi. I'm in the process of preparing to sell my Helios64. If you interested let me know. (I'm selling it as one of the HD power rails does not bring the needed voltage anymore ... and I need more disks now).
  2. I'm not an expert here, but I have struggled with "failed" disks quite some time meanwhile ... According to your dmesg you disk has no link 2.670580] ata1: SATA link down (SStatus 0 SControl 300) I'd interpret this as "there is no disk plugged in" ... so I'd guess it is more a cable topic. So I'd do the obvious: Make sure that the disk is properly plugged in and really reaches the connectors of the backplane. Inspect the cable harnes from the other side, is it really correctly installed. In worst case: remove the cable from the vaulty slot and plug it directly into the disc.
  3. Just for the files, in case anyone is interested: It seems my power rail A is faulty. I measured the voltages ... if no disk is connected I have 4.90V (which is a little less in my opinion). If I connect a disk to rail A, the power drops down to 4.10V ... I guess this is far too low to have the disk(s) start up successfully. Not sure how to deal with that at the moment. Intended to use the 12V of rail A with a step down converter to get my needed 5V (I have 2.5" disks, no need for 12V), but it seems that the 12V are not switched of, if the helios64 is down. It still provides 12V ... For the moment I have removed the original SATA harness and replaced it with my own cables - having 3 disks on rail B. Works for the moment.
  4. Hi there ... Not sure if anyone has an idea here, but I have the following topic: I have a helios64, equipped with 3 2.5" disk drives, running Debian 10 with Kernel 5.10.43. Usually the system runs stable ... even for days (24/7). But every now and then the disks "fail" - which means, during normal operation suddenly the disk turn of, linux reports "sata link down" ... and the disks are off. As if they were removed. If I reboot I usually here only some "klicks" ... I assume the disks try to spin up, but fail due to not enough power (?). To recover from that situation, I usually disconnect power (incl. the internal UPS) ... try a few times, and sooner or later disks power successfully up again. Then the system run's again for a while without any issues. I already tried to re-cable everything, trying to ensure that the cables are properly connected, but this does not seem to help. I assume that there is an hardware issue with the SATA power rails (both show the same effect). For that reason I'm looking for the schematics, to trace that a little deeper ... anyone an idea if they are somewhere available? Thanks!
  5. Not sure if this is something you want to consider: Using a Rasperry Pi 4 Compute Module ("CM4") it is possible to build a not too bad NAS To use the CM4 you need a "IO Board" (e.g. https://www.berrybase.de/raspberry-pi/raspberry-pi-computer/compute-modules/raspberry-pi-compute-module-4-io-board). The IO board has a PCIe port - and there you can plugin e.g. a 6bay SATA card. So in the end you get RP4 with as many SATA ports as you want / need. I have this running (but not in the enclosure of the Helios64) - performance is not that good as of the Helios64, but pretty close. It is running without any issues so far. The size of the system could fit into the Helios64 enclosure - some tinkering will be needed of course.
  6. They were. But you should also see the other side: I purchased Helios64 with the assumption of buying a solid and reliable NAS system - which is linux based = open. I also had the assumption that Kobol will support the device for at least 2-3 years ... What I got was: A definitively cool and powerful Linux NAS system where Wake on Lan does not work (although it was advertised) ... and prop. never will work (one of my reasons to buy!) where the 2.5 GB LAN port only works reliable with 2.5 GB ... (except you're willing to solder SMD - and risk to mess it up completely)(I was under the - reasonable - assumption that this port will also work well with GB LAN ... one reason to buy!) where the SATA Ports / cables seem to have troubles (at least my btrfs degrades every now an then, according to the forum, others have the same issue ...) ... a solution will never be available! where it is hard to get a running updated system, as you're in the risk of losing functionality where you will get no spare parts, etc. anymore ... also no second (replacement) unit (unless you want to buy an used one - which is not that easy, as they are rare). where you will get no real support anymore (also "support" and "warranty" was rather limited anyhow). ... My personal conclusion: A rather mixed feeling ... I did not really get what I bought. I'm now sitting on an island, which I have to take as it is, depending on "the community" for each upgrade (and for security reasons sometimes you need to update!). Technically the best thing to do would be to sell the unit. I expected that these type of products, coming from China/Singapur, heavily relaying on the community, have "limited" durability. But - for me - less than a year, was really unexpected to me! So even if Kobol team would return, not sure if I ever would buy from them again ...
  7. The question is, if you would trust them again ... they pulled the trigger already once and let their customers alone.
  8. Thanks! Digged a little bi deeper in - the rules are actually mostly from openmediavault, did not realize that there were some set up before! Thanks to both on you for pointing me in the right direction!
  9. Hi, sorry, prop. a stupid question - but I was so far not figuring out the answer. I have a helios64 running - pretty standard installation, including openmediavault and docker, as described on the kobol help page. I realized that there are some firewall/iptables rules are set, as example: tester@helios64:/etc# sudo iptables -L Chain INPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED ACCEPT icmp -- anywhere anywhere state NEW,RELATED,ESTABLISHED ACCEPT tcp -- anywhere anywhere tcp dpt:http ACCEPT tcp -- anywhere anywhere tcp dpt:https ACCEPT tcp -- anywhere anywhere tcp dpt:8384 ACCEPT tcp -- anywhere anywhere tcp dpt:3128 ACCEPT tcp -- anywhere anywhere tcp dpt:1443 ACCEPT udp -- anywhere anywhere udp dpt:domain ACCEPT tcp -- anywhere anywhere tcp dpt:domain ACCEPT tcp -- anywhere anywhere tcp dpt:microsoft-ds ACCEPT tcp -- anywhere anywhere tcp dpt:netbios-ssn ACCEPT udp -- anywhere anywhere udp dpt:netbios-dgm ACCEPT udp -- anywhere anywhere udp dpt:netbios-ns ACCEPT tcp -- anywhere anywhere tcp dpt:ftp ACCEPT tcp -- anywhere anywhere tcp dpt:49152 ACCEPT tcp -- anywhere anywhere tcp dpt:22000 ACCEPT udp -- anywhere anywhere udp dpt:1900 Chain FORWARD (policy ACCEPT) target prot opt source destination DOCKER-USER all -- anywhere anywhere DOCKER-ISOLATION-STAGE-1 all -- anywhere anywhere ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED DOCKER all -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere ... What I was not able to figure out is, where these rules come from!? In openmediafault no firewall rules are set. I also was not able to find any iptables settings in /etc/network, etc. Anyone an idea where these rules are configured? And with which service they are setup? Thanks!
  10. My Helios is "semi-table". The only issue I'm having is every now an then a "lost" disk in ZFS - usually during high load. uname -a Linux helios64 5.9.14-rockchip64 #20.11.4 SMP PREEMPT Tue Dec 15 08:52:20 CET 2020 aarch64 GNU/Linux
  11. From my wishlist: Wake on Lan - yep, I know that Helios64 supports WOL, but practically it is still not working a properly wired 2.5 GB connector - yep, I know, but it is frustrating anyways, especially due to the warranty handling of kobol (send it back on your risk, wait 2 month, send a replacement back, wait another 2 month, hope it works) standard SATA connectors - my ZFS fails rather often due to checksum errors, this seems to be related to bad cables. With the shipped non-standard cables, this is however hard to solve. If the enclose / board had standard connectors, I could simply use one of the 1000 cables laying around here. more RAM - or support for standard ram modules and yes, the sliders for the disks need a redesign, too (color is cool, but they are rather "cheap" and you need a lot of power to push them in / pull them out)
  12. Thanks for the hint with the cables, unfortunately they are rather hard to replace Interesting enough, I've today removed the luks layer for all three disks, so my pool is now using the disks directly. As (unexpected) result, scrub now completes without degrading the pool - at least it worked three times today without problems. So it seems for the moment that the lusk encryption was the source of my issue.
  13. Hi, I have major issues with my helios64 / ZFS setup - maybe anyone can give me a good hint. I'm running the following system: Linux helios64 5.9.14-rockchip64 #20.11.4 SMP PREEMPT Tue Dec 15 08:52:20 CET 2020 aarch64 GNU/Linux I have a three WD 4TB Plus disk - on each disk is encrypted with luks. The three encrypted disks are bundled into a raidz1 zpool "archive" using zfs. Basically this setup works pretty good, but with rather high disc usage, e.g. during a scrub, the whole pool degrades due to read / crc errors. As example: zpool status -x pool: archive state: DEGRADED status: One or more devices are faulted in response to persistent errors. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Replace the faulted device, or use 'zpool clear' to mark the device repaired. scan: scrub in progress since Sun Jan 10 09:54:30 2021 613G scanned at 534M/s, 363G issued at 316M/s, 1.46T total 7.56M repaired, 24.35% done, 0 days 01:00:57 to go config: NAME STATE READ WRITE CKSUM archive DEGRADED 0 0 0 raidz1-0 DEGRADED 87 0 0 EncSDC DEGRADED 78 0 0 too many errors (repairing) EncSDD FAULTED 64 0 0 too many errors (repairing) EncSDE DEGRADED 56 0 20 too many errors (repairing) errors: No known data errors dmesg shows a lot of these errors: [Jan10 09:59] ata3.00: NCQ disabled due to excessive errors [ +0.000009] ata3.00: exception Emask 0x2 SAct 0x18004102 SErr 0x400 action 0x6 [ +0.000002] ata3.00: irq_stat 0x08000000 [ +0.000004] ata3: SError: { Proto } [ +0.000006] ata3.00: failed command: READ FPDMA QUEUED [ +0.000007] ata3.00: cmd 60/00:08:e8:92:01/08:00:68:00:00/40 tag 1 ncq dma 1048576 in res 40/00:d8:68:8b:01/00:00:68:00:00/40 Emask 0x2 (HSM violation) [ +0.000002] ata3.00: status: { DRDY } [ +0.000004] ata3.00: failed command: READ FPDMA QUEUED [ +0.000006] ata3.00: cmd 60/80:40:e8:9a:01/03:00:68:00:00/40 tag 8 ncq dma 458752 in res 40/00:d8:68:8b:01/00:00:68:00:00/40 Emask 0x2 (HSM violation) [ +0.000002] ata3.00: status: { DRDY } [ +0.000003] ata3.00: failed command: READ FPDMA QUEUED [ +0.000005] ata3.00: cmd 60/80:70:68:9e:01/00:00:68:00:00/40 tag 14 ncq dma 65536 in res 40/00:d8:68:8b:01/00:00:68:00:00/40 Emask 0x2 (HSM violation) [ +0.000003] ata3.00: status: { DRDY } [ +0.000002] ata3.00: failed command: READ FPDMA QUEUED [ +0.000006] ata3.00: cmd 60/80:d8:68:8b:01/01:00:68:00:00/40 tag 27 ncq dma 196608 in res 40/00:d8:68:8b:01/00:00:68:00:00/40 Emask 0x2 (HSM violation) [ +0.000002] ata3.00: status: { DRDY } [ +0.000002] ata3.00: failed command: READ FPDMA QUEUED [ +0.000005] ata3.00: cmd 60/00:e0:e8:8c:01/06:00:68:00:00/40 tag 28 ncq dma 786432 in res 40/00:d8:68:8b:01/00:00:68:00:00/40 Emask 0x2 (HSM violation) [ +0.000002] ata3.00: status: { DRDY } [ +0.000007] ata3: hard resetting link [ +0.475899] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ +0.001128] ata3.00: configured for UDMA/133 [ +0.000306] scsi_io_completion_action: 8 callbacks suppressed [ +0.000009] sd 2:0:0:0: [sdd] tag#1 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 cmd_age=0s [ +0.000006] sd 2:0:0:0: [sdd] tag#1 Sense Key : 0x5 [current] [ +0.000003] sd 2:0:0:0: [sdd] tag#1 ASC=0x21 ASCQ=0x4 [ +0.000006] sd 2:0:0:0: [sdd] tag#1 CDB: opcode=0x88 88 00 00 00 00 00 68 01 92 e8 00 00 08 00 00 00 [ +0.000003] print_req_error: 8 callbacks suppressed [ +0.000003] blk_update_request: I/O error, dev sdd, sector 1744933608 op 0x0:(READ) flags 0x700 phys_seg 16 prio class 0 [ +0.000019] zio pool=archive vdev=/dev/mapper/EncSDC error=5 type=1 offset=893389230080 size=1048576 flags=40080cb0 [ +0.000069] sd 2:0:0:0: [sdd] tag#8 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 cmd_age=0s [ +0.000005] sd 2:0:0:0: [sdd] tag#8 Sense Key : 0x5 [current] [ +0.000003] sd 2:0:0:0: [sdd] tag#8 ASC=0x21 ASCQ=0x4 [ +0.000004] sd 2:0:0:0: [sdd] tag#8 CDB: opcode=0x88 88 00 00 00 00 00 68 01 9a e8 00 00 03 80 00 00 [ +0.000004] blk_update_request: I/O error, dev sdd, sector 1744935656 op 0x0:(READ) flags 0x700 phys_seg 7 prio class 0 [ +0.000014] zio pool=archive vdev=/dev/mapper/EncSDC error=5 type=1 offset=893390278656 size=458752 flags=40080cb0 [ +0.000049] sd 2:0:0:0: [sdd] tag#14 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 cmd_age=0s [ +0.000004] sd 2:0:0:0: [sdd] tag#14 Sense Key : 0x5 [current] [ +0.000004] sd 2:0:0:0: [sdd] tag#14 ASC=0x21 ASCQ=0x4 [ +0.000003] sd 2:0:0:0: [sdd] tag#14 CDB: opcode=0x88 88 00 00 00 00 00 68 01 9e 68 00 00 00 80 00 00 [ +0.000004] blk_update_request: I/O error, dev sdd, sector 1744936552 op 0x0:(READ) flags 0x700 phys_seg 16 prio class 0 [ +0.000013] zio pool=archive vdev=/dev/mapper/EncSDC error=5 type=1 offset=893390737408 size=65536 flags=1808b0 The S.M.A.R.T values of the discs are OK - only "UDMA_CRC_ERROR_COUNT" are increased (values ~25, increasing). What's also worth mentioning: If I start a scrub I get these errors after about 10 seconds (rather quickly) - but it seems that if I let the scrub continue, there are no more errors occuring. Does this indicate bad discs? The discs itself do not indicate any problems (selftest does not show issues). Is this related to the zfs implementations for armbian? Anything I can do to get this reliable? Thank!
  14. That's why I wrote / read 5 GB ... the Helios64 has "only" 4 GB RAM, so if 5 GB are read / writen the cache should be have no useable copy of the data.
  15. Thank you for your answer. I know about ashift=12, my tests have been made with this setting. I also tried your settings (without compression!), but they make no real difference. Using three disks brings things up to ~80MB/s - which is still unacceptable. But I think I found my problem: It is actually related to the blocksize - but not the blocksize of the zfs pool - but the blocksize dd is using: This is what I'm usually doing: root@helios64:/test# dd if=test2.bin of=/dev/null 9765625+0 records in 9765625+0 records out 5000000000 bytes (5.0 GB, 4.7 GiB) copied, 107.466 s, 46.5 MB/s DD is using a blocksize of 512 here. For ext4 / btrfs this seems to be no issue - but zfs has a topic with this. If I use explicity a blocksize of 4096, I get these results: root@helios64:/test# dd if=test2.bin of=/dev/null bs=4096 1220703+1 records in 1220703+1 records out 5000000000 bytes (5.0 GB, 4.7 GiB) copied, 27.4704 s, 182 MB/s Which gives the figures expected! So as so often: "Layer 8 problem" - the problem sits in front of the screen.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines