6 ms·
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
by kabdib 10y ago
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.
- gambiting 10y agoSDXC 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.
- hengheng 10y agoWorth noting that rarely any 2.5" HDD is faster than 100 MByte/s at 100 iops. This SD card could well come near that.
- cm2187 10y agoI wish but I am yet to see an SD card exceeding 10MB/s in practice.
- gambiting 10y agoKingston 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_review http://www.storagereview.com/kingston_sdhc_sdxc_uhsi_u3_revi...
- bluedino 10y agoWhat device and card are you using? The MacBook Pro will do 90/40 http://images.anandtech.com/reviews/mac/retinaMacBookPro/quickbenchrMBP.jpg http://images.anandtech.com/reviews/mac/retinaMacBookPro/qui...
- deleted 10y ago[deleted]
- qyv 10y agoUSB3 'plug & stay' drives seem like a better option for expanding laptop storage than SD cards these days.
- soylentcola 10y agoI'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.
- dingaling 10y ago> 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
- rodgerd 10y ago> 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.
- FireBeyond 10y agoAbsolutely. 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.
- Someone1234 10y ago> 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?
- jrockway 10y agoFlash 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.
- TickleSteve 10y agowear-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.
- lallysingh 10y agoI think when someone on HN refers to a specific piece of tech as magic, they're not saying that it's literally magical.
- kabdib 10y agoFlash 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.
- jrockway 10y agoI 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.
- prawn 10y agoSpeed 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.
- agopaul 10y agoConsidering the low price of SD cards, I was thinking about doing the same thing: buy a 128GB SD and use it for cold storage
- kabdib 10y agoRead 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.
- cmg 10y agoAnecdotally, 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.)
- cft 10y agoHow 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.
- wazoox 10y agoWeird, 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.
- vardump 10y agoThat'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)