Hacker News Reader

Comment by kabdib | Hacker News Reader

Its performance is going to be glacial. Example: I have a 1.2 TB Fusion I/O flash drive on my workstation; it gets about 2 GByte / second sustained, and it has heat sinks and extra power connectors for a reason. Extrapolate down to a dinky piece of plastic that has about the same amount of storage; trade-offs were made.

And you should look really, really hard at retention when it is not powered (do the bits leak away, past recovery by ECC, when it's been on the shelf for six months?) Also look at reliability (transaction-nature) when it experiences unplanned ejects or power loss.

View on HN

> And you should look really, really hard at retention when it is not powered (do the bits leak away, past recovery by ECC, when it's been on the shelf for six months?)

Aside from the components physically degrading (or environmental factors like radiation), I've never heard, read, or experienced this issue. Why do you believe this SD card would be susceptible to data loss after as little as six months?

Flash is actually super lossy (especially non-SLC technology), it only appears to durably store your data because of error correction and redundancy.

This is something I never realized until I worked on an embedded system where every bit error showed up as a log message. It made me think, "how can computers work at all"? The answer is math and abstraction layers that work a little bit better than the average web framework.

wear-levelling and bad-block management are not magic.

The failure modes of FLASH are well-known, they dont necessarily need abstraction layers and they do work very well and reliably.

I think when someone on HN refers to a specific piece of tech as magic, they're not saying that it's literally magical.

Flash storage management is still hard to get right, especially when the power can be removed at any time. Making data structures resilient to arbitrary power removal while having good performance is quite a feat.

I used the word math, not magic.

There are many abstraction layers involved. For example, your Linux application isn't bit-banging the NAND chips directly. Your SoC knows there's flash attached, and handles it accordingly. Or, the Linux MTD layer handles it. Then, there are the flash-specific filesystems, like ubifs.

All in all I find it pretty interesting, because if you "echo foo > /dev/mtdX", you're not going to find any sequence of flash cells that contain the bit pattern 0x66 0x6f 0x6f 0x0a for very long after you do that write. And yet everything works anyway. There is a _high probability_ that you will be able to read it back, but there it's never guaranteed.

Nothing is ever guaranteed. All we can do is increase the probability of success.

Right, and usually SD cards don't have anywhere the level of FTL's that SSD's have. In fact its likely there isn't much of a FTL at all, rather just a simple ECC on the flash pages. Lose more bits in that page than the ECC can correct, and the whole card is basically done because it can't relocate sectors. SD isn't meant to be primary storage. Its meant to be used more like floppies/usb sticks.

I can't tell you how many android phones I "fixed" for a couple years by replacing the SD cards. I actually had a sandisk 128G fail on me a couple weeks ago, that was just sitting in a dell/windows tablet with little more than a few movies copied to it. It didn't last 6 months, I guess something in win10 must have been rewritting a date/time stamp or something similar to the same sector long enough that the card just started hanging doing reads until it became bad enough that windows would choke and I noticed it.

Back about 10 years ago, I had an ARM device with an SD slot that I was writing firewall logs to. The SD cards in that machine would last ~2 months before they died. Eventually I replaced the SD cards with a USB attached SSD in an enclosure, and that fixed the problem.

> that work a little bit better than the average web framework

you have a reference for this? which aspects did you compare or were compared?

I think that was intended to be a joke, as when I think of the average web framework, I see buggy junk.

Multiple-bits-per-cell is astonishingly involved; with three bits the electronics has to distinguish between eight voltage levels in the face of process variations and environmental conditions that vary widly. There aren't that many electrons in these cells to begin with, and the charges leak over time. I think of the engineering that goes into this stuff as "heroic." 4 bits per cell and you're talking full bull-goose crazy. My hat's off to ya (no, I'm not going to buy any of that).

So you ECC the shit out of things and hope. Or you use less ECC, get more "checkbox capacity" on the box the consumer sees, and most people won't experience failure until they throw the device away. It's all about margins.

SSDs, even the expensive ones you buy, don't have a super long shelf life and are not what you want to use for backup media.

This, a million times, this.

It's a stunning paradox that densities and adoption is growing dramatically all the while raw retention gets worse with every generation (an astonishing amount of smarts goes into mitigating media deficiencies).

I'm not too concerned (assuming the standard backups) about devices in continuous and powered-on use, but for data at rest, powered off, this is very scary.

It gets even more scary: So you back up all your data to disks? Sure, they're pretty cheap and you can buy a terabyte for fifty bucks, but guess what the firmware for those drives is stored on. Hope the flash they used wasn't cheap (but if it's a consumer drive and it cost you fifty bucks, it probably was).

For long life I'm betting on DVDs (refreshed every few years). Easily half of the 15 year old drives I've been keeping are now bad; copying them forward every few years is a good idea. It might be time to go back to tape, but it's expensive. Pretty much everything sucks at retention.

Or just pay $100/yr to back it up to Dropbox (or even cheaper AWS Glacier)?

Because in a 3-bit flash cell, there are on the order of 10 electrons separating one charge level from the next. If a couple too many decide to quantum-tunnel their way to freedom, the bits will flip.

Flash is very heat sensitive. It doesn't take a lot of thermal energy to allow those trapped electrons to migrate.

Lower temps need more time but can still cause loss, higher temps less time.

Semi-dumb semi-serious question, what's the gradient on this heat sensitivity? How much difference does it make to (eg.) keep a flash drive in a freezer?

Somewhere there are graphs or tables of retention vs. read/storage/write temperatures.

SDXC U3 cards can easily write at 90MB/s, which is obviously nowhere near 2GB/s of a fusion drive, but it's definitely good enough for recording 4K video and taking large pictures - which is what this card is going to be used for. No one expects it to replace your SSD.

Worth noting that rarely any 2.5" HDD is faster than 100 MByte/s at 100 iops. This SD card could well come near that.

I wish but I am yet to see an SD card exceeding 10MB/s in practice.

Kingston UHS3 gets over 90MB/s in sequential read/write, and over 10MB/s in random read/write:

http://www.storagereview.com/kingston_sdhc_sdxc_uhsi_u3_revi...

What device and card are you using? The MacBook Pro will do 90/40

http://images.anandtech.com/reviews/mac/retinaMacBookPro/qui...

How did you test 2GB/sec? I have a Fusionio ioDrive2 1.2 TB card in a 32 core Xeon E5 server with 1600Mhz RAM and I get only 850MB/sec:

    # for i in {1..4} ; do ( time sh -c "dd if=/dev/zero of=/fusionio1/ddtest.$i bs=1M count=4000 oflag=direct" ) ; done
    4000+0 records in
    4000+0 records out
    4194304000 bytes (4.2 GB) copied, 4.90524 s, 855 MB/s

    real    0m4.908s
    user    0m0.006s
    sys     0m0.785s
    4000+0 records in
    4000+0 records out
    4194304000 bytes (4.2 GB) copied, 5.05399 s, 830 MB/s

Server has 128GB RAM and the card is in a PCIe 3.0 slot. Also FusionIO has 20PByte write endurance, which sandisk card obviously doesn't need.

Weird, even on an old PCIe 2.0 Opteron machine, I easily gets 1.4 GB/s from an HGST NVMe card. I've got 800 MB/s from a single SAS 12Gb SSD. Something's probably wrong in your setup.

How do you measure the write speed?

Same as you, good ol' dd. Not using direct IO, though. But I'm watching at iostat while testing, and the results are coherent.

That's suspiciously low.

Some questions:

1) What happens if you use bigger block sizes, say 16M?

2) Which filesystem you're using? Can it be fragmented? Can you test with raw disk to eliminate any filesystem influence?

3) Is dd running on same NUMA node (CPU socket) as your ioDrive2 PCI-e link?

4) To expand on 3, is there chance for QPI saturation (traffic between CPU sockets)? Have you ensured all the software uses CPU local RAM whenever possible and not access other CPU socket's RAM?

5) Are you sure all PCI-e lanes are active? (Try lspci)

Also: Did you low-level format to 4K blocks, or is is still using 512 byte blocks? Various options for the kernel module also have a significant effect, as do BIOS settings (C-states, etc.).

I got 2.5-2.9 GB/sec (iirc) with a FusionIO ioDrive2 Duo. It has been more than a year so I do not remember all the details.

Check the power status of the card. Make sure it's getting enough juice.

http://sirsql.net/content/2015/02/12/fusionio-and-the-go-fas...

Nothing fancy, just multiple copies of large files at the filesystem level, making sure that the cache wasn't giving false results. The transfer rates and the I/O counters matched pretty well. This was on a vanilla Windows 10 workstation.

We run a bunch of these things, and regularly bump up against the PCIe bus limits. There's something going on with your setup.

Speed is obviously one. I have a large microSD card that I have permanently in the SD card slot of my MBP with a BaseQi caddy. I wouldn't use it to read-write work data, but it works well as a (mostly) read-only store for MP3s.

Considering the low price of SD cards, I was thinking about doing the same thing: buy a 128GB SD and use it for cold storage

Read elsewhere in this thread. Don't rely on cheap flash for archiving, you'll lose it. Think on the order of a year or so.

Anecdotally, I can relate to this. I bought a 256GB SD card to store my music on and kept it plugged in to my laptop. It died just about a year later, and showed reliability issues before that.

(Of course, my "backup" was my iPod Classic, which was stolen from my car shortly before the SD card died, but that's another story.)

USB3 'plug & stay' drives seem like a better option for expanding laptop storage than SD cards these days.

I'm thinking the early uses will be primarily video cameras and similar recording devices that need small, easily swappable "drives" that can handle large files. When you're on a shoot, you don't want to keep swapping storage media every 30 or 60 minutes. In our little studio (university setting so not as high end as a pro shoot) we use swappable drive bays in a recorder. Those just hold standard SSDs and can be popped out and plugged into an edit station for capture and transfer. Still not cheap though and ours are typically 512GB drives.

> When you're on a shoot, you don't want to keep swapping storage media every 30 or 60 minutes.

You really should, though. Not in the filming domain but in stills, I've shot airshows in the company of professional[0] photographers who changed their cards for fresh ones after every act. No point losing a whole day's shooting to one bad card.

Apparently this is also common at weddings, though even more so as the photographer might be taking shots of the same scene on two different cameras and then changing cards in both. Just in case.

[0] as in, they are paid for their output

> Apparently this is also common at weddings, though even more so as the photographer might be taking shots of the same scene on two different cameras and then changing cards in both. Just in case.

More common is the requirement to have a camera that supports dual cards, so you can either write to both cards, or write JPG to one and RAW to the other, so you'll never lose everything.

Absolutely. I will typically take 4-6 cards to shoot a wedding, though I could buy a 64/128GB card and shoot everything on one.

Touch wood, though, I am yet to have a CF failure. But I also pay for the most reliable.

When I looked at the overhead for USB3 bulk transfers on Windows the system was spending a lot of time in the I/O and memory system stack (doing lots of page-wiring, and just going through layers).

External USB storage is find for archival and low volume use, but not great for anything you want performance out of.

Then again, on a laptop you probably don't have much choice . . .

UASP should help with that - but both the host and device need to support it.

Reply on news.ycombinator.com