101–110 of 190 posts
Earlier quoted context omitted.
There's a pretty succinct (2 minute) non-engineering description of how a nuclear reactor works in the Chernobyl miniseries you might want to check out: https://www.youtube.com/watch?v=BpwU4mtWXAE
Why is that scene so pointlessly edgy? Is the whole show like that?
Or 30, if you believe the govt. report.
Since the firmware is more complicated than hard drives, they are way more likely to brick themselves completely instead of a graceful degradation. Manufacturers can also have nasty firmware bugs like https://www.techpowerup.com/261560/hp-enterprise-ssd-firmwar... . I'd recommend using a mix of SSDs at different lifetimes, and/or different manufacturers, in a RAID configuration.
How different manufacturers deal with running SMART tests under load drastically varies. Samsung tests always take the same amount of time. The length of Intel tests vary depending on load. Micron SMART tests get stuck if they are under constant load. Seagate SMART tests appear to report being at 90% done or complete, but the tests do actually run.
Different SSDs also are more or less tolerant to power changes. Micron SSDs are prone to resetting when a hard disk is inserted in the same backplane power domain, and we have to isolate them accordingly.
Manual overprovisioning is helpful when you aren't able to use TRIM.
What a drive does with secure-erase-enhanced can be different too. Some drives only change the encryption key and then return garbage on read. Some additionally wipe the block mappings so that reads return 0.
"As for writes, at 1 gb a day - far more than my current rate of data use - it would take the same 114 years to reach 40 tb." Maybe it works for author's very specific system or use-case, but on my personal MBP laptop with very occasional usage pattern--some days I do not use it at all during the week--I end up with 10 GB per day of writes on average. That way it will be 11.4 years already, not so many. And I do not…
How much RAM do you have? And how many Chrome tabs?
I check Data written in the Activity monitor — Disk.
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…
For example, even something as trivial and linear as a database log or filesystem log can benefit from placement optimisation.
Each time there's a transaction to commit, instead of writing the next commit record to the next LBA number in the log, increment the LBA number by an amount that gives a sector that is about to arrive under the disk head at the time the commit was requested. That will leave gaps, but those can be filled by later commits.
That reduces the latency of durable commits to HDD by removing rotational delay.
Command queueing doesn't help with that, although it does help with keeping a sustained throughput of them by pipelining.
Earlier quoted context omitted.
> 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…
Native command queuing won't help with placement decisions . (And the NCQ queue is rather short anyway for scheduling optimisation.) For example, even something as trivial and linear as a database log or filesystem log can benefit from placement optimisation. Each time there's a transaction to commit, instead of writing the next commit record to the next LBA number in the log, increment the LBA number by an amount th…
Isn't it 31 or 32 commands in the queue? That's a worst-case of around a quarter second for a 7200rpm drive, which sounds like an awfully long time horizon to me.
Things I've learned from using SSDs at prgmr: Since the firmware is more complicated than hard drives, they are way more likely to brick themselves completely instead of a graceful degradation. Manufacturers can also have nasty firmware bugs like https://www.techpowerup.com/261560/hp-enterprise-ssd-firmwar... . I'd recommend using a mix of SSDs at different lifetimes, and/or different manufacturers, in a RAID configu…
"As for writes, at 1 gb a day - far more than my current rate of data use - it would take the same 114 years to reach 40 tb." Maybe it works for author's very specific system or use-case, but on my personal MBP laptop with very occasional usage pattern--some days I do not use it at all during the week--I end up with 10 GB per day of writes on average. That way it will be 11.4 years already, not so many. And I do not…
I guess what I’m saying is that for modern SSDs I don’t think write endurance is a binding constraint in most cases.
Earlier quoted context omitted.
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.
Having only 2 or 4 planes per die with per-die capacities of 32GB or more is a big part of why current SSDs need to be at least 512GB or 1TB in order to make full use of the performance offered by their controllers. 265GB SSDs are now all significantly slower than larger models from the same product line.
The part about filesystems is slightly incorrect. > The way the file system handles this is incompatible with the workings of NAND flash. That's true of most conventional filesystems, but log-structured filesystems are much more flash-friendly. That's why there has been a resurgence of interest in them, and also why a typical flash translation layer bears a striking resemblance to a log-structured FS. There are also…
> to an HDD all sectors are the same. Also I believe some humans, and (filesystems?) intentionally stored certain data towards the inside/outside of the HDD because the simple cylinder geometry allowed faster reads in those regions. However, I'm not seeing conclusive proof that modern HDDs show performance variation with respect to radius.
> Deleted file recovery on a modern SSD is next to impossible for the end user OK, he’s talking about SSDs, but I want to mention that I’ve easily recovered many large deleted files from SD or micro-SD cards (formatted as FAT32 or exFAT) using Norton Unerase or an equivalent utility. Are the controllers for SSDs that different from the controllers for SD cards? Has anyone tried Norton Unerase or an equivalent program…
In other words, when you "delete" a FAT file, you are not even erasing a whole directory entry, you just merely flip one bit in that entry.
The data blocks get actually "erased" when they are reused by the FS software.
Recovery of basic deletion is therefore pretty much guaranteed as long as you didn't write something else on the disk.
What the author is talking about is more "serious" deletion, sometimes called "shredding" [1]. To actually erase the data from the disk, you use software that overwrite your file with random data before deleting it. This is supposed to work if the filesystem is as clever as FAT - that is somewhat dumb (but so simple that SoCs such as ARM Cortex Ax can boot from them directly).
SDs and SSDs add another challenge because they constantly lie to the filesystem software; they have their own inner controller mainly to manage bad sectors and do wear-leveling, so when the FS requests to fill a sector with zeros, they might say "ok" but actually just remap the sector internally to another empty sector. So the data is still somewhere on the chip, and an evil scientist with lots of pointy probes can in theory read them back.