Mixing HDD and SSD in a ZFS Mirror

One of my test bad computers had a ZFS mirror between its internal 2.5" HDD (ST20000LM003) and external My Passport 2.5" USB 3.0 HDD (WDC WD20NMVW-11W68S0). And yes, having a mirror between SATA and USB is not the most ideal solution to start with, but it does work. In any case, setup happily chugged along until recently when the internal drive started having faults. Replacement was in order.

But replacing an old 2 TB drive proved not to be so easy. When it comes to 2 TB 2.5" models, all laptop drives manufactured these days are SMR. While you can use them in ZFS pool, performance is abysmal during resilvering. Normal use might be ok, depending on load, but it wouldn’t be as good as CMR. The only way to get equivalent drive to the one I had was to get a refurbished years old drive. Not ideal.

But then my eyes went toward cheap 2 TB SSDs. For just a $10 more, I could get a (somewhat) faster drive. However, searching on Internet, I noticed that idea of mixing HDD and SSD in the same pool seems to be frowned upon.

And yes, I knew that you won’t get full benefits of either HDD or SSD when using them together in the same pool but it seemed like an arbitrary limitation especially when price in 2 TB range is essentially equivalent. Why wouldn’t you use SSD when drive needs replacing?

So I ordered myself a cheap SSD and tried to see if there are any downsides to mixed HDD/SSD setup.

The first test I did was an FIO sequential read/write (fio-seq-RW.fio). With two HDDs in mirror, I was at 148/99 MB/s for read/write, respectively. After changing the internal drive to SSD, speeds went to almost identical 147/98 MB/s. Adding a single SSD brought no practical difference in this scenario. Based on this test alone, I would have said that while SSD doesn’t bring a performance improvement, it doesn’t drag it down too much. Having an SMR drive in this setup would bring performance down more than this low-price SSD ever could.

The second test I tried was random read/write (fio-rand-RW.fio). Here speed with two HDD was 480/320 KB/s while combination of HDD and SSD brought speed all the way to 4980/3330 KB/s. Essentially ten-fold increase in performance. If you have virtual machines running on top of ZFS you will feel the difference.

The third test was just to verify if previous two tests looked sensible (ssd-test.fio). While numbers did differ slightly, overall data looked the same. No improvement when it comes to sequential access (even a slight performance decrease) but a huge improvements for random data access.

My conclusion is that, while replacing HDD with SSD might not be the most cost effective approach when it comes to larger pools, there is nothing bad about it as such and, depending on your workload, you might see a healthy improvement. It’s not an appropriate solution when it comes to larger drives, but for pools having up to 2 TB drives, go for it!

PS: For curious, here is raw testing data.

PPS: No, I don’t want to talk about who hurt me that much that I’m willing to use an external USB as part of a mirrored pool.

Type-C Power Delivery as Passive PoE Source - Firmware

This is part 3 out of 3 in the series. PCBs were sponsored by PCBWay.

The firmware for the old ResetBox had a simple setup. You press the button shortly, it gets ignored; you press it for a second or two, and you reboot the devices. However, the introduction of the PD negotiation required a way to configure the voltage.

The easy way would be simply to use the existing external button for configuration. And that would work just fine. However, this would also mean that one could accidentally (or more likely by messing with the front panel) change the voltage. I didn’t want that. Thus the second, internal, button was born.

With it, the second question popped - why not use the internal button to set the voltage and the external button to change the setting. Since two buttons are there, both can be used. Except there aren’t two buttons available at all times. If we go with my rack-mounting case, the button is mounted in the rack using a rather short cable. If we get the device on the table, we don’t want to unmount the button. So, it has to be a single button setup.

Thus, the first thing that firmware checks during boot time is the state of the button. If the button is pressed, the boot process waits for either 3 seconds to elapse or for the button to be released. If the button is released within that time, just proceed with the normal boot. If the button is still pressed, go into configuration.

While I use TIMER0 for time management, I avoid using interrupts for just measuring the duration of time presses. The reason behind this is that I like to have interrupts available for the stuff that matters (e.g., change on the external pin). It doesn’t matter if the press is 3 or 3.01 seconds long, and thus, just checking the timer state is good enough.

Essentially, all time loops are as follows:

while {
    if (timer0_wasTriggered()) {
        counter++;
        if (counter == COUNTER_MAX) {  // held it long enough
            // do something for holding
        }
    }
}

As I set up timer pre/post-scalers in such a manner that I have exactly 24 “triggers” per second, an 8-bit counter variable allows for 10 seconds to pass. If a longer duration is needed, you can use 16-bit integers, but I usually find 10 seconds to be plenty.

Another change I made to the firmware was the ability to cancel the reset. In the old version, once you press the button for 3 seconds, it will reset the device when you release the button. Well, it happened at least once that I pressed the button for 3 seconds and then discovered that I pressed the wrong one. However, there was no way to go back.

In the new firmware, I lowered the duration needed to enter into the reboot mode to 2 seconds, but I also allowed for cancel if one holds it for an additional 10 seconds. As before, one can know if the release will reset the device by the LED brightness. If the LED gets dim, the reset is imminent.

For a simple device like this one, this is more than enough flexibility.

Source code is available on GitHub. And you can also check previous posts about design and its fixes.

Type-C Power Delivery as Passive PoE Source - Fixes

This is part 2 out of 3 in the series. PCBs were sponsored by PCBWay.

The first version of any project is rarely without faults. And this one is not an exception.

The simplest issue has been me simply forgetting to wire up enable lines on 74HC238D decoder. I assumed, for no good reason, that lines were enabled by default. Thus, no matter what my code did, LEDs stayed dark. After a bit of probing and seeing correct voltage on input, I decided to check the datasheet again and saw the issue almost immediately. A fix required two wires though, as G2A and G2B lines required pull-down while pull-up was required for G1.

The next issue I noticed was that my internal button wouldn’t work. I knew of this risk since, due to pin shortage on PIC12F1501, I ended up using this pin as both input and output. As the microcontroller was booting, I wanted to detect button presses so I can put it into configuration mode. If the button wasn’t pressed during configuration, I would simply use the same pin as power-on signal input towards the transistor. Well, in theory, that should have worked. In practice, I had it pull to ground via an external base resistor. In order to keep the transistor at a known level when the line is input, I used my bodge powers to make the button pull the line high when pressed. Here is where my habit of connecting only two legs of the four-legged button actually helped as I was able to simply snip off one leg and solder 3V3 to another.

With the configuration mode sorted out, I started switching voltages only to find out that I am maxing at 9 V. I could select 5 V just fine but no matter what higher voltage I selected, CH224K would give me 9 V. It took me a while and a lot of datasheet deciphering (Chinese-only datasheet didn’t help) to understand what was happening.

You see, there are two ways you can configure CH224K. You can either use 3 CFG lines to set the desired input state in binary or you can use a resistor on CFG1 line alone. My 10K series resistor made the chip think I was using a single-resistor setting. 10K was close enough to 6.8K so that’s where 9 V came from. In 5 V mode, I had that pin pulled high, and that was enough to stop the single-resistor setup. The solution was to remove series resistors altogether. Ironically, I didn’t actually need them but decided to place them anyhow to help with troubleshooting.

One thing that definitely did help with this troubleshooting was the quality of the PCB. For example, while trying to troubleshoot my voltage settings, I soldered and resoldered CH221K multiple times. Since ground is on the pad that is inaccessible to a soldering iron, I had to reheat the board multiple times. I honestly expected to damage the solder mask after the second time getting it to 300 °C. And while the smell wasn’t the best, the PCB handled it without problems. Yes, you can damage the solder mask if you really want to but it will take a lot more than heavy-handed rework to do so.

With bodges sorted out, the next step will be to update the firmware.

Gone Cold

On paper, there’s little not to love about Pinecil v2. It’s a nice portable soldering iron, it uses low-ohm tips allowing for quick heating, uses the sweet type-C power, and at $25 it’s quite a deal. Do I need another soldering iron? Not really. But such deal was simply too tempting to pass.

As it often happens, my enthusiasm led me to buy two irons, some extra tips, nice silicone type-C cables, and even the darn replacement tip contacts. And no, I didn’t buy both for myself - one I figured was a perfect present for a friend.

The shipment arrived reasonably fast and I immediately tested it. I still preferred my KSGER but the Pinecil seemed quite usable when I needed to solder something quickly without getting the big guns out. I definitely believe there is a place in my arsenal for something like this. However, in a practical sense, it would always be my second choice. Thus, over a 3-month period, I found myself using the Pinecil only a few times.

And then it came time for some microsoldering on Framework HDMI Expansion Card. It was a single-wire mod but QFN package made it ideal work for the Pinecil. So, for maybe the 10th time in 3 months, I inserted its soldering tip, plugged it into a type-C charger, and… nothing. It was bereft of life.

After trying a fAfter attempting several solutions suggested online, I finnally contacted Pine64 support. They responded almost immediately, asked me for order number and requested pictures of my power supply, only to follow up with an extended silence. After a week or so, I got bored and pinged them to see what the status is, only to be informed that the warranty for the Pinecil was merely one month and there was nothing more they could do.

I don’t care how cheap the product is but 1 month warranty is not acceptable. Either you stand behind your product or you don’t. By having warranty match no-questions-asked-return period offered by most retailers, it’s clear that they’re doing the bare minimum. I would argue that a one-month warranty equates to virtually no warranty at all.

Should have I known that before I made the purchase? Maybe. Maybe not. But as I am in the market for a new portable soldering iron, one thing is certain: my new portable iron will not be a Pinecil. Not because it died - that happens. It’s purely because I know I cannot count on company for any support. And if they’re not willing to support their customers, it’s reasonable to assume they’re doing the bare minimum with their manufacturing process as well.

Are other portable soldering iron companies the same? Possibly, but that remains to be seen. However, with the Pinecil, the adage “buy cheap, buy twice” certainly proved true. And at $50, it’s not exactly a budget device anymore.

PS: My friend’s Pinecil still works. Alternatively, maybe it died but he’s too thoughtful to tell me. :)

Type-C Power Delivery as Passive PoE Source

This is a part 1 out of 3. PCBs were sponsored by PCBWay.

A long time ago I decided upon passive 48 V PoE for my network. Choice was made due to both hAP ac and Audience access points supporting up to 57 V. Thus 48 V was closest lower standard value with a reasonably priced power supplies. However, this decision came to bite me in the ass with my new hAP ax³ supports going only up to 28 V. Placing it into my network would lead to a lot of sparking fun. What I needed was a lower voltage.

Well, the next logical step was switching to 24 V. However, buying two 24 V power supplies (one to use, and one for backup) allowing for 60 W was actually not that cheap. Since I had bunch of leftover power supplies, I started to wonder if I could use something I already have.

Yes, I could have used one of vendor-specific laptop power supplies but that would involve cutting cables as their connectors were anything but standard. The only standard connector I had was type-C. And then it hit me. Why not simply use power delivery to get 20 V out of it?

Realistically, probably the easiest in-place replacement was one of many prebuilt cables out there. And I think this is the best way to go if you just need power. But, for my home setup I connected PoE over ResetBox device which allows for an easy power reset. Wouldn’t it be really nice if I updated ResetBox to directly use type-C?

And no, ResetBox is not just a simple switch albeit it offers essential functionality of one. Its a bit smarter than that as it contains microcontroller that gets to control a relay. For example, it will ignore short, accidental, presses and allow reset only when held for 3 seconds. Ideal for controlling things you don’t want to reset by accident - for example your home wireless network.

For this update it would be ideal to switch input to type-C, allow for on-board voltage selection (5 V, 9 V, 12 V, 15 V, and 20 V), and lastly have a nice way to indicate the selected voltage.

With that in mind, the first task became selection of PD chip. It is possible to control PD on your own but I quickly decided against it as setting it to function right with various PD and non-PD type-C devices would take ages. No, I wanted something standard.

Quick search quickly pointed toward IP2721 as a reasonably easy to (hand)solder device used in many existing triggers. However, its package was a bit on a large side and voltage output was quite limited since it only supported 5 V, 15 V, and 20 V operation. Definitely not a full set of voltages I wanted. And yes, you could get lower voltages by using IP2721_MAX12 variant but then you lose the higher voltage options.

Second device I found was HUSB238 and I immediately liked its SOT33-6L variant. Unfortunately, this easy-to-solder variant was nowhere to be found for purchase. Even worse, the chip didn’t support the full PD 3.0 5A operation. Yes, probably not a deal-breaker for this particular scenario as 60 W was plenty but still no ideal for a new design.

After quite a lot of additional search I stumbled across CH224K. Not only it came in (seemingly) easy to solder ESSOP-10 package but it also supported easy control. Based on a few examples I found it seemed possible to tease the full 100 W with it. The datasheet also mentions an even more appealing CH221K in the SOT23-6L package, but I had difficulty finding it in the market. On the other hand, the ESSOP-10 variant was readily available all over AliExpress.

With chip selected, the second order of business became figuring out how to connect all this. With only 6 I/O pins available, the current PIC12F1501 was a bit crowded. In addition to 1 button input, 1 LED output, and a 1 relay output it already handled, I would add 3 outputs for voltage control (also used to show LEDs status). Total of 1 input and 5 outputs. Not comfortable but just enough.

Originally, ResetBox had the option to handle AC input. However, with type-C, this is no longer necessary, so we can replace the relay with a small P-MOSFET and completely bypass the diode bridge. We don’t control this MOSFET directly, but rather via a small NPN transistor. This approach serves two purposes: first, it prevents our PIC from seeing 20 V at any given time, and second, it allows the PG signal to override the output (i.e., no PG, no voltage).

While originally ResetBox had option to hadnle AC input, with type-C we don’t need this anymore and thus we can replace relay with a small P-MOSFET and omit diode bridge altogether. We don’t control this MOSFET directly but over a small NPN transistor and that’s for two reasons. First one is to avoid our PIC seeing 20V at any point in time and the second reason is allowing PG signal to override output (i.e., no PG, no voltage).

The power supply for the main PIC is managed by an LDO. While this approach does waste some energy, it’s not too significant as the PIC won’t need more than roughly 20 mA. For such a small current, it simply wasn’t worth opting for a switched-mode regulation. I considered using a 5 V LDO despite the input being at 5 V, but chose to make the smarter decision and go with 3.3 V instead. And yes, I did test the 5 V LDO in the same circuit and it worked, albeit with a slight voltage drop.

For PCB creation I chose PCBWay and they generously provided me with free PCBs. As it’s common with my projects, I don’t really push the boundary of what’s possible but there were a few non-standard things with this PCB. The first one was its thickness as I needed 0.8 mm due to type-C connector. The second one were really small holes for the same. And yes, this was quite well within the specification but I actually had issues with this when it came to other PCB manufacturers.

But more about that the next time when I go over all the things I’ve botched during the PCB design.

Latest design is available on GitHub