WD SN850 delivers the best performing SSD we've tested
tweaktown.com
tweaktown.com
Is this actually good advice, especially without mentioning the durability risks?
There's simply no good reason to periodically write your data from flash to $other every now and them, and then back to flash. There are heaps of other ways to prevent data loss or performance degradation in flash storage.
There are methods like tiered storage, where only the most active data is present in Flash-storage, much like write back caching.
This makes no sense. The main problem with disabling write flushing is what happens if the OS crashes or the power goes out. Doing periodic backups/restores provides a "last known good state" to revert to, but you'll still lose all the writes between the last backup and when you crashed. Depending on your workload this might be fine, but I doubt the COO is going to be pleased when he finds out you lost all customer orders from today.
The bit about "restoring periodically" also doesn't make any sense because such events are easily detectable. There's no need to constantly take the system offline to do a restore. Disabling write flushing isn't going to cause increased bitrot.
But if you think that your FB or Youtube or Fidelity or Geico or SSN or IRS or Apple or Google data isn't sitting on a tape somewhere, you are extremely mistaken, because I was the one who wrote the tape control software they purchased from us.
A researcher desires to download a 50 minute archived video. A request is sent from their laptop to a lookup table server. The lookup table contains the metadata for where that file is stored.
Then the request is passed to a media server which has an SSD and RAM large enough for receiving the actual media file. It opens a connection with the tape library. The tape library handles loading the media from tape to a staging server, which also has an SSD.
So totally the media file goes from tape, to staging SSD via hardwire, to main server's SSD over the network, to client's device over the network.
Exactly! Use ceph so you don't have to care about burning ssd/hdd/server/switch/racks/dc, you have your object-storeage, FS, block-device, with one service and that's it.
It's essentially the typical "without this enabled, you will lose data in case of power loss, potentially breaking the O/S".
I bought one that should power my internet+wifi for about an hour for $45.
I guess even a small one like that would handle power blips for a home server, but in an outage the battery would quickly run out and the setting would matter.
I didn't do a lot of research, my main goal was to not have interruptions when the power blinks off.
There's APC and Amazon basics models that are about the same capacity and price.
can you elaborate on this? What's the exact difference? Do sata drives get more aggressive buffer flushing than nvme drives?
But the end result is that in the default state (buffer flushing enabled), most or all disk benchmarking tools show drastically lower write performance on consumer NVMe drives than should be expected compared to their theoretical advantage over SATA SSDs.
I'm not intimately familiar with the semantics of how flush/sync commands get generated and passed through the Windows IO stack. Empirically, when an application tries to issue a write that is not to be buffered by the OS, it appears that Windows translates that into NVMe commands that constrain or entirely prohibit the SSD from doing its own write buffering, but for SATA SSDs writes are still by default issued in a manner that permits the drive to buffer freely. Figuring out exactly what's happening without Microsoft's help might require bus analyzers I don't have. In effect, it seems that Windows is less willing to trust a NVMe SSD than a SATA SSD, and that doesn't strike me as justified.
I've also noticed that recent builds of Windows 10 have changed their behavior when running one of our old benchmarking tools that plays back IO traces. On current Windows 10, the OS outright rejects any attempt by the trace playback application to issue a flush command to a NVMe SSD, whether or not buffer flushing is enabled at the driver level. This is definitely a change from earlier builds of Windows 10, and I think it is a change that only affects NVMe drives, not SATA drives. (I'm not testing very many SATA drives these days, and have to design my testing procedures entirely around the needs of testing NVMe drives.)
This... doesn't seem to be the case? If you look at this chart[1] from anandtech, you can see that the nvme drives (crucial P1, intel 660p) are significantly ahead of the sata drives (860 evo, 860 qvo, crucial mx500). The sustained write results[2] worse for nvme drives, but they're still better than similar sata drives if we control for flash type (qlc vs tlc) and capacity.
Also, comparing nvme drives to sata drives is hard to begin with, since they're usually in different price segments. sata drives tend to be cheaper than nvme drives (maybe the controller is cheaper?), so if you were comparing a sata drive and a nvme drive of the same price, you might end up with a "worse" nvme drive because of the nvme premium.
[1] https://images.anandtech.com/graphs/graph13633/burst-rw.png
[2] https://images.anandtech.com/graphs/graph13633/sustained-rw....
crucial p1:
https://images.hothardware.com/contentimages/article/2843/co... (169.8 MB/s)
https://cdn.mos.cms.futurecdn.net/nVhtVJZ64vDP7coALo7y3T-970... (162 MB/s)
samsung 860 evo:
https://i1.wp.com/www.tech-critter.com/wp-content/uploads/20... (118.25MB/s)
https://www.notebookcheck.net/fileadmin/Notebooks/Schenker/X... (122.8 MB/s)
No thanks. I'll be skipping that site in the future, unless that javascript comes from a place I can easily block with pi-hole.
Why on earth are you you blocking javascript using dns? Shouldn't you be doing it via the browser (via addons or site preferences)?
document.addEventListener('copy', (event)=>{
const pagelink = `\n\nRead more: ${document.location.href}`;
event.clipboardData.setData('text', document.getSelection() + pagelink);
event.preventDefault();
})
To prevent this make a custom extension "run_at": "document_start"
and inject window.addEventListener('copy', e => e.stopImmediatePropagation(), true);
alternatively use for example https://www.tampermonkey.net with Experimental Inject Mode: Instant
to inject your pacifying script.I ended up getting a Samsung Evo 970 plus (1TB) a while ago because it was in a sale for $85. Almost half the speed of the ones in the benchmark. Maybe I should have waited.
And 1/3 the price. If you bought it because it was on sale, doesn't that mean you're at least somewhat price sensitive? I don't think you should feel bad about your purchase.
Even in the latter, full text indexing which every platform has had for years now makes it much less likely that the full directory tree will even get walked, and differences even less likely to be noticed. As a side note, every desktop platform's full text search seems to suffer software performance problems that are largely independent of the underlying disk
Even in the full-tree enumeration case, since Spectre/Meltdown mitigations landed, system call overhead is so high now that even with a lightning fast disk, a large chunk of total time taken to walk the directory tree is lost basically twiddling the CPU mode securely. You can definitely still see the difference between SATA and NVMe, but you can also definitely measure the amount of time during the NVMe run that is spent in software -- incrementally faster NVMe will have quickly diminishing returns.
"What about databases!" This was my original interest in SSDs to begin with. It turns out, despite being a data monkey who loves large databases, since 2013 any time I've worked with a giant dataset like this, it is always in the form of large scans (usually from something like a CSV or XML file), where SSDs don't really have a mind-blowing advantage over magnetic (but of course they are still 5-10x faster a seq io, its just that data parsing and processing is typically the bottleneck now).
It says in the article.
The only time I max out my sata scratch drive is when I’m unpacking a video. Playing a 4K and a 1080p video at the same time barely spikes my ZFS pool on my NAS.