Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Everything I Know About SSDs

kcall.co.uk

Post reply on HN
Print view View original

91–100 of 190 posts

Re: Everything I Know About SSDs

#91

Post by BenjiWiebe »

xioxox wrote: post #25
creeble wrote: post #13

Anyone know how TRIM works with Linux? I find myself copying entire partitions between SSDs from time to time, is there a utility to clear the destination SSD before copy? Is it possible to do the same for an SD card, so that writing a new Raspi OS to it doesn't do unnecessary garbage collection?

On linux, it can either get done using fstrim (often run periodically, e.g. via cron), which clears unused blocks, or can be done on file delete on supported file systems (e.g. mounting using the discard option). The periodic trim is supposed to be better, as a SSD does guarantee that a trim returns quickly. If you want to trim an entire device, see blkdiscard (take care!).

On a systemd based system, you may have fstrim.timer enabled by default. Check: sudo systemctl status fstrim.timer

Re: Everything I Know About SSDs

#92

Post by wtallis »

TremendousJudge wrote: post #71
winrid wrote: post #31

Earlier quoted context omitted.

Not OP but in my experience people tend to have trouble comprehending systems of planetary gear sets. Although modern automatics are probably a bit easier to understand than old ones, especially CVTs? As long as you're ok with "the computer just triggers this solenoid.." rather than understanding a big hydrualic computer.

Modern automatic transmissions are actually manual transmissions with a robot moving through the gears as far as I know. However, they do a bunch of stuff that I don't understand like pre-engage the next gear so the switch is faster -- I have no idea how that works

> like pre-engage the next gear so the switch is faster -- I have no idea how that works

I think you're referring to dual-clutch transmissions: odd gears on one clutch, even gears on the other. So the transmission can switch from eg. gear 2 to 4 with the even-numbered clutch disengaged while transferring power through the odd-numbered clutch in gear 3. When it's time to move up to gear 4, one clutch is disengaged as the other is engaged, instead of having to leave a single clutch disengaged while the gear change happens.

Re: Everything I Know About SSDs

#93

Post by cartoonworld »

TremendousJudge wrote: post #71
winrid wrote: post #31

Earlier quoted context omitted.

Not OP but in my experience people tend to have trouble comprehending systems of planetary gear sets. Although modern automatics are probably a bit easier to understand than old ones, especially CVTs? As long as you're ok with "the computer just triggers this solenoid.." rather than understanding a big hydrualic computer.

Modern automatic transmissions are actually manual transmissions with a robot moving through the gears as far as I know. However, they do a bunch of stuff that I don't understand like pre-engage the next gear so the switch is faster -- I have no idea how that works

Yeah they sure are, they are manual transmissions with a solenoid controlled dual-clutch setup. One clutch engages the next gear as the first releases, there is no lost thrust as with a single clutch pedal, and you get to save all the weight of hauling around a huge valvebody and fluid and clutch bands.... Great stuff.

The Howstuffworks article is great. Have fun. https://auto.howstuffworks.com/dual-clutch-transmission.htm

Re: Everything I Know About SSDs

#94

Post by lostgame »

It lost me at Comic Sans, and made me almost ill with any further font and design choices.

So I finally kicked it into Reader View, only to find a lot of questionable spelling and grammar issues.

These kinds of basic things go a long way to making an article valuable.

Re: Everything I Know About SSDs

#95

Post by SlowRobotAhead »

wtallis wrote: post #81
bb88 wrote: post #73

Earlier quoted context omitted.

The big problem with one data center drive is that if that goes bad, you still lose all your data. You're assuming their marketing MTBF is correct. They do make NVME raid solutions now -- with the advantage being that NVME can be faster than SATA. And there are various price points for the NVME drives depending upon speed. This one from 2018 (not sure if it has full raid or uses VROC)(EDIT: it requires software raid)…

Almost all NVMe RAID products—including both that you've linked to—are software RAID schemes. So if you're on Linux and already have access to competent software RAID, you should only concern yourself with what's necessary to get the drives connected to your system. In the case of two drives, most recent desktop motherboards already have the slots you need, and multi-drive riser cards are unnecessary.

PERC HP740 controllers in Dell servers iirc are hardware raid for the flex port U.2 and backplane pcie nvme drives.

Re: Everything I Know About SSDs

#96

Post by wtallis »

0xff00ffee wrote: post #90

Excellent summary. One thing he left off: some SSDs continue to copy/erase blocks even if there is nothing new to write because multi-level cell state does degrade over time. There is a concern that some MLC drives will suffer bit corruption over time if not regularly power up to allow this in the background. Citation needed: I only recall this when I was interviewing to work for Western Digital many years ago.

This problem was most prominent right before the switch to 3D NAND, when planar NAND dimensions were at their smallest and the consumer market had already mostly switched over to 3 bit per cell TLC rather than 2bpc MLC. In the worst case, we were down to about 8 electrons difference between cell voltage states. That's now been relaxed by 3D NAND allowing for larger cell sizes, and most 3D NAND also switched from floating-gate to charge-trap cell design so leakage is less of an issue. Nowadays, data retention in SSDs is only a concern toward the end of their lifespan (as measured by write endurance), and it's probably inadvisable for the SSD to start doing background data scrubbing until the raw read error rate starts climbing.

Re: Everything I Know About SSDs

#97

Post by notacoward »

zozbot234 wrote: post #88
tzs wrote: post #85

Earlier quoted context omitted.

At some point, I think around the mid '90s or early 2000s but maybe earlier, though, seek time was fast enough on widely available drives that on average for random access you spent about as much time on the right cylinder waiting for the sector you wanted to rotate to under the head as you did on seeking to the right cylinder. You could get some decent gains then if you made your scheduler take rotation into account…

> I don't think that there were any drives that would tell you this. SCSI drives wouldn't even tell you the geometry. IDE drives would tell you a geometry, but it didn't necessarily have anything to do with the actual geometry of the drive. I thought the point of native command queuing was precisely to enable the drive itself to make these lower-level scheduling decisions, while the OS scheduler would mostly deal wit…

> I thought the point of native command queuing was precisely to enable the drive itself to make these lower-level scheduling decisions

The main purpose of NCQ (and SCSI command queuing which came way before it) was to allow higher levels of parallelism at the drive interface. This does allow the drive to do some smart scheduling, but still only within that fairly small queue depth. Scheduling across larger numbers of requests, with more complicated constraints on ordering, deadlines, etc., remains the OS's job. And once it's doing that, the incremental benefit of those on-disk scheduling smarts becomes pretty small.

Re: Everything I Know About SSDs

#98

Post by nybble41 »

eMGm4D0zgUAVXc7 wrote: post #79
zozbot234 wrote: post #24

Earlier quoted context omitted.

> I find myself copying entire/ partitions between SSDs from time to time, is there a utility to clear the destination SSD before copy? The way TRIM works, you don't need to trim blocks right before overwriting them. TRIM is for blocks that you aren't going to care about for quite some time, it essentially returns them to the SSD management layer for use as overprovisioning.

> The way TRIM works, you don't need to trim blocks right before overwriting them. In my experience "blkdiscard /dev/DESTINATION_DISK" does improve the speed of dd'ing a disk to another one quite a bit though. And that does make some sense IMHO: If the SSD's internal datastructure which keeps track of pages which hold user-data is empty then each write will consume less time for looking up if the specific sector is c…

It also avoids wasting time (and write endurance) shuffling around data which is just going to be overwritten anyway. That could happen either as a result of static wear leveling or just because the drive needed to erase a block with a mix of valid and overwritten pages to make room for new data.

Re: Everything I Know About SSDs

#99

Post by wtallis »

SlowRobotAhead wrote: post #95
wtallis wrote: post #81

Earlier quoted context omitted.

Almost all NVMe RAID products—including both that you've linked to—are software RAID schemes. So if you're on Linux and already have access to competent software RAID, you should only concern yourself with what's necessary to get the drives connected to your system. In the case of two drives, most recent desktop motherboards already have the slots you need, and multi-drive riser cards are unnecessary.

PERC HP740 controllers in Dell servers iirc are hardware raid for the flex port U.2 and backplane pcie nvme drives.

Yes, that's one of the cards that use Broadcom/Avago/LSI "tri-mode" HBA chips (SAS3508 in this case). It comes with the somewhat awkward caveat of making your NVMe devices look to the host like they're SCSI drives, and constraining you to 8 lanes of PCIe uplink for however many drives you have behind the controller. Marvell has a more interesting NVMe RAID chip that is fairly transparent to the host, in that it makes your RAID 0/1/10 of NVMe SSDs appear to be a single NVMe SSD. One of the most popular use cases for that chip seems to be transparently mirroring server boot drives.

Re: Everything I Know About SSDs

#100

Post by dr_zoidberg »

wtallis wrote: post #67
dr_zoidberg wrote: post #55

Earlier quoted context omitted.

Ok, I've studied the Flash storage (most SSDs these days) technolgy and can be understood like this: * At the "lowest" level, there's a little cell that it's very much an EEPROM (but better, because newer tech). This little cell can hold 1, 2, 3 or 4 bits, depending on gen/tech. * You group a bunch on those cells together and they form a page. Usually it's 1024 cells a page. * You group a bunch of pages together and…

Your quantities are way off if you're trying to describe the kind of NAND flash that goes into SSDs. Typical page sizes are ~16kB plus room for ECC, so a page is several thousand physical memory cells, not just one thousand. Erase blocks are several MB, so at least a thousand pages per erase block. A single die of NAND typically has just 2 or 4 planes, each of which is at least 16GB.

Largest sizes I'm finding for erase blocks are 128 and 256KB, not several MB. I am finding larger plane sizes, that probably comes from grouping more blocks together. In general, it's not massively different from what I described, it's just a difference in sizes involved at the higher levels.
Post reply on HN