

Gareth Halfacree
-
Content Count
21 -
Joined
-
Last visited
Reputation Activity
-
Gareth Halfacree got a reaction from jbergler in Random rant
No, I was not: I was asking the vendor of the network attached storage device I paid for if there was a convenient way of upgrading its bootloader. Your input was neither requested nor desired.
Perhaps this is a language barrier thing, so allow me to be clear: you are being extremely hostile. When people post on this specific sub-forum, it's with the expectation they're engaging in a professional discourse with the people who support the device they paid for - i.e. Kobol. They are not attacking you personally, nor the Armbian project: they, like I, simply want to get the device they paid for to work as promised. Jumping down their throat claiming that "we owe you nothing" and demanding additional payment on top of the device cost is hostile.
I'm a technology journalist, and I've already published two reviews of the Helios64 and Armbian on the Helios64. Given your attitude, I will be updating those reviews to warn that unless you're willing to either write the code yourself or contribute to Armbian's - absolutely ridiculous, from your claims - running costs you will not be able to seek assistance with the software - even from Kobol itself - without being attacked. I will further recommend that readers avoid the Armbian project as a whole, and any device which relies upon it.
I feel that you've lost sight of the goals of your project: what is an operating system without its users?
-
Gareth Halfacree got a reaction from jbergler in Random rant
I am calm. What I am not is accepting of abuse.
-
Gareth Halfacree got a reaction from gprovost in SATA issue, drive resets: ataX.00: failed command: READ FPDMA QUEUED
I'd suggest getting one or more drives, setting them up in a btrfs mirror, dding a bunch of random onto them, and scrubbing. It's possible dding alone will trigger the error, but if it doesn't then scrubbing certainly should.
$ sudo mkfs.btrfs -L testdisks -m raid1 -d raid1 /dev/sdX /dev/sdY /dev/sdZ $ sudo mkdir /media/testdisks $ sudo chown USER /media/testdisks $ sudo mount /dev/sdX /media/testdisks -o user,defaults,noatime,nodiratime,compress=zstd,space_cache $ cd /media/testdisks $ dd if=/dev/urandom of=/media/testdisks/001.testfile bs=10M count=1024 $ for i in {002..100}; do cp /media/testdisks/001.testfile /media/testdisks/$i.testfile; done $ sudo btrfs scrub start -Bd /media/testdisks
The options on the mount are set to mimic my own. Obviously change the number and name of the devices and the username to match your own. It's also set to create 100 files of 10GB each for a total of 1TB of data; you could try with 10 files for 100GB total first to speed things up, but I've around a terabyte of data on my system so figured it was worth matching the real-world scenario as closely as possible.
-
Gareth Halfacree got a reaction from Alexander Eiblinger in SATA issue, drive resets: ataX.00: failed command: READ FPDMA QUEUED
It's the first of the month, so another automated btrfs scrub took place - and again triggered a bunch of DRDY drive resets on ata2.00. Are we any closer to figuring out what the problem is, here?
-
Gareth Halfacree reacted to clostro in Feature / Changes requests for future Helios64 board or enclosure revisions
@Gareth Halfacree If you would be interested in FreeBSD, @SleepWalker was experimenting with it some time ago. Maybe still is.
-
Gareth Halfacree reacted to gprovost in No "Install" option in armbian-config - how to upgrade bootloader?
Ok here the dirty way to update it in your specific case where eMMC is at /dev/mmcblk1
We will work on nand-sata-install to support the use case of rootfs on HDD/SSD and bootloader on eMMC.
-
Gareth Halfacree got a reaction from allen--smithee in Encrypted OpenZFS performance
Your MicroServer has either an Opteron or Ryzen processor in it, either one of which is considerably more powerful than the Arm-based RK3399.
As a quick test, I ran OpenSSL benchmarks for AES-256-CBC on my Ryzen 2700X desktop, an older N54L MicroServer, and the Helios64, block size 8129 bytes.
Helios64: 68411.39kB/s.
N54L: 127620.44kB/s.
Desktop: 211711.31kB/s.
From that, you can see the Helios64 CPU is your bottleneck: 68,411.39kB/s is about 67MB/s, or within shouting distance of your 62MB/s real-world throughput - and that's just encryption, without the LZ4 compression overhead.
-
Gareth Halfacree got a reaction from wurmfood in Encrypted OpenZFS performance
Your MicroServer has either an Opteron or Ryzen processor in it, either one of which is considerably more powerful than the Arm-based RK3399.
As a quick test, I ran OpenSSL benchmarks for AES-256-CBC on my Ryzen 2700X desktop, an older N54L MicroServer, and the Helios64, block size 8129 bytes.
Helios64: 68411.39kB/s.
N54L: 127620.44kB/s.
Desktop: 211711.31kB/s.
From that, you can see the Helios64 CPU is your bottleneck: 68,411.39kB/s is about 67MB/s, or within shouting distance of your 62MB/s real-world throughput - and that's just encryption, without the LZ4 compression overhead.
-
Gareth Halfacree got a reaction from TRS-80 in Encrypted OpenZFS performance
Your MicroServer has either an Opteron or Ryzen processor in it, either one of which is considerably more powerful than the Arm-based RK3399.
As a quick test, I ran OpenSSL benchmarks for AES-256-CBC on my Ryzen 2700X desktop, an older N54L MicroServer, and the Helios64, block size 8129 bytes.
Helios64: 68411.39kB/s.
N54L: 127620.44kB/s.
Desktop: 211711.31kB/s.
From that, you can see the Helios64 CPU is your bottleneck: 68,411.39kB/s is about 67MB/s, or within shouting distance of your 62MB/s real-world throughput - and that's just encryption, without the LZ4 compression overhead.
-
Gareth Halfacree got a reaction from clostro in Encrypted OpenZFS performance
Your MicroServer has either an Opteron or Ryzen processor in it, either one of which is considerably more powerful than the Arm-based RK3399.
As a quick test, I ran OpenSSL benchmarks for AES-256-CBC on my Ryzen 2700X desktop, an older N54L MicroServer, and the Helios64, block size 8129 bytes.
Helios64: 68411.39kB/s.
N54L: 127620.44kB/s.
Desktop: 211711.31kB/s.
From that, you can see the Helios64 CPU is your bottleneck: 68,411.39kB/s is about 67MB/s, or within shouting distance of your 62MB/s real-world throughput - and that's just encryption, without the LZ4 compression overhead.
-
Gareth Halfacree got a reaction from Koen Vervloesem in Encrypted OpenZFS performance
Your MicroServer has either an Opteron or Ryzen processor in it, either one of which is considerably more powerful than the Arm-based RK3399.
As a quick test, I ran OpenSSL benchmarks for AES-256-CBC on my Ryzen 2700X desktop, an older N54L MicroServer, and the Helios64, block size 8129 bytes.
Helios64: 68411.39kB/s.
N54L: 127620.44kB/s.
Desktop: 211711.31kB/s.
From that, you can see the Helios64 CPU is your bottleneck: 68,411.39kB/s is about 67MB/s, or within shouting distance of your 62MB/s real-world throughput - and that's just encryption, without the LZ4 compression overhead.
-
Gareth Halfacree reacted to FloBaoti in [SOLVED] Helios64 won't boot after latest update
Here is mine (not yet upgraded) :
Maybe problem could be on rootdev UUID ? For me it refers to /dev/mmcblk1p1