EEVblog Electronics Community Forum
Products => Computers => Topic started by: harerod on October 06, 2023, 09:53:47 pm
-
This thread prompted me to finally request your expertise about keeping data on backup SSD's:
https://www.eevblog.com/forum/general-computing/help-me-choose-qty6-sata-disks-for-my-multi-node-nas/msg5094024/#msg5094024 (https://www.eevblog.com/forum/general-computing/help-me-choose-qty6-sata-disks-for-my-multi-node-nas/msg5094024/#msg5094024)
Background: I keep a double set of spare components for some critical computers. All software is legal and payed for. Since the activation servers have gone offline (Microsoft, Adobe, ...), I clone the system SSD's to allow for quick recovery in some fault scenarios.
Independent of SSD brand - what would be a good strategy to "exercise" the SSD's to keep their memory? I assume that occasional power-up and idling for several hours wouldn't do much. Under which conditions can one assume that the internal SSD controller would refresh/maintain the data? As was hinted in the other thread- maybe a read (Linux dd of the whole storage comes to mind)?
Another thing, but only a work-around, could be a dd-dump of the SSD onto a different disk and then trying to restore that. I will have to check if this would keep all licenses active.
Again, the specific question is - under which scenario is a backup SSD most likely to retain its data for several years?
-
The topic was touched here (https://www.eevblog.com/forum/general-computing/ssd-vs-hdd-for-data-security/msg5075539/#msg5075539), but unfortunately that was never clarified. :(
Error detection and correction is an inherent part of data encoding in the SSD itself, so any read triggers it for the data being accessed. So reading the entire medium should suffice:cat /dev/yourssd >/dev/nullOr, using pv to see progress (https://www.ivarch.com/programs/pv.shtml):
pv -ctrabp /dev/yourssd >/dev/null
While this is guaranteed to work, it is suboptimal. It requires transferring all the data to RAM and it reads sectors in random order. SSD’s built-in mechanisms could do better. Which is why I asked for clarification in the other thread.
-
I don't think it's really possible to answer this question in general, as it will depend to a large extent on the SSD's controller and its firmware. While they probably all use similar strategies to "refresh" content, the minute details of how and when they do that is not known to the public and likely varies quite a bit from one drive to the next.
Whether powering them on on a regular basis with no data access at all, with just basic filesystem access (so no particular action from the user, but plugged to a computer running some OS), or having to explicitely *access* the data area for which you want to maximize the odds of it being checked and refreshed if necessary, is enough, I have like zero answer to that. And as I just said, it probably depends on the controller's firmware to a large extent.
I doubt you actually need to explicitely access data on the drive to guarantee retention, otherwise any files that would be stored but rarely accessed on your SSD would run the risk of data corruption, and that would be like such a major downside to using SSDs that consumers would really not enjoy the idea. My guess is that most controllers probably check for different areas cyclically and transparently, so users don't have to access actually files to ensure retention. But I have never run into the source code of an SSD's firmware, so all bets are open.
-
Not entirely sure if SiliconWizard’s answer is referring to my post or not. If not, ignore this.
Error detection and correction is not an “emergency” procedure,(1) but an inseparable part of data encoding. Which is why reading data must invoke verification and, if needed, refreshing. Reading the entire storage area will inevitably ensure its refreshing where needed. The problem is that, as I mentioned earlier, this method is not optimal.
What I wrote should not be read in opposite direction. Active reading requires refreshing, but refreshing doesn’t require active reading. During normal operation, while SSD is powered often and for extended periods of time, firmware may perform verification in the background. But in this case this is not going to work.
(1) In the distant past the perception was different, which is why we still encounter the opposite view persists today.
-
I always do full backup and delete the oldest one. I use 7zip with zero compression level (store) and noticed that copying speed is different for command line, GUI and when adding to archive through FAR manager. I've created a batch file that puts my work folder to ZIP on USB SSD drive, filename contains current date and time. Unfortunately batch process slows down to 60mb/s after some time, so I temporary switched to FAR manager add to archive option, which is surprisingly provides 100 to 200 mb/s speed and moves 100gb+ work folder to backup location in less than 15 minutes (same 7zip dll). I have three SSD drives and cycle through them from time to time to be safe. On fast CPUs you can try ZSTD compression. Archive can be tested using 7z checksums. I don't know method to maintain old backups other than simple copying.
-
My guess is that most controllers probably check for different areas cyclically and transparently
this is most likely the case :-//
I don't like SSDs because they need command extensions and precautions in the drivers (firmware on the SBC and kernel side) which frankly I don't have the desire or time to support
-
The topic was touched here (https://www.eevblog.com/forum/general-computing/ssd-vs-hdd-for-data-security/msg5075539/#msg5075539), but unfortunately that was never clarified. :(
...Code: [Select] (https://www.eevblog.com/forum/javascript:void(0);)cat /dev/yourssd >/dev/nullOr, using pv to see progress (https://www.ivarch.com/programs/pv.shtml):Code: [Select] (https://www.eevblog.com/forum/javascript:void(0);)pv -ctrabp /dev/yourssd >/dev/null...
Thanks for backing up my initial thoughts and for the Linux command sequences. I wonder if there are any built-in functions of Windows that would trigger the same behaviour. Maybe run checkdisk?
My fastest dedicated Linux box is a Raspi3 (with a new Raspi4 waiting to be set up), otherwise I run VMware images under Windows. While connecting the SSD's to the Raspi via a USB docking station should work, the performance would be an order of magnitude below the SSD's potential. (guesstimate: 1TB/30MB/s ~ 10h)
-
I assume you also store your mission critical SSDs in a fire resistant 'disc safe'?
-
Not entirely sure if SiliconWizard’s answer is referring to my post or not. If not, ignore this.
Error detection and correction is not an “emergency” procedure,(1) but an inseparable part of data encoding. Which is why reading data must invoke verification and, if needed, refreshing. Reading the entire storage area will inevitably ensure its refreshing where needed. The problem is that, as I mentioned earlier, this method is not optimal.
What I wrote should not be read in opposite direction. Active reading requires refreshing, but refreshing doesn’t require active reading. During normal operation, while SSD is powered often and for extended periods of time, firmware may perform verification in the background. But in this case this is not going to work.
(1) In the distant past the perception was different, which is why we still encounter the opposite view persists today.
yup, that old trick is sufficient but not necessary; in my opinion it's likely that there are some firmware commands, or proprietary extensions, which internally invoke { reading, verification, refreshing }, but done in an optimal way.
Here we need to understand if the documentation is public :-//
-
I use AOMEI Backupper to create backup files of any drives like this.
Just restored an SSD for a machine this morning using it.
Close to 1:1 in terms of backup so a 20GB Windows install with software is only ~20GB file.
Of which you can store anywhere including the "cloud" so no need to worry about physical media.
-
My current backup strategy includes writing changed files to the backup SSD and removing deleted files so the content of both volumes is the same, and then creating a hash file of the source, and checking the entire backup with that hash file, so all content and metadata get read on both the source and backup.
In theory this will find (and report) any corrupted sectors on both, and on an SSD, it should force the scrub-on-read operation if a sector is failing.
-
My current backup strategy includes writing changed files to the backup SSD and removing deleted files so the content of both volumes is the same, and then creating a hash file of the source, and checking the entire backup with that hash file, so all content and metadata get read on both the source and backup.
In theory this will find (and report) any corrupted sectors on both, and on an SSD, it should force the scrub-on-read operation if a sector is failing.
What happens if a file is deleted or corrupted and you don't notice before a backup occurs? This sounds more like a manual RAID1.
-
For leaving with no power for long term, you want as minimum cell levels as possible. SLC would be perfect, but not really an option these days. So it should be MLC or at least no worse than TLC. Also it should be a brand new drive or with minimal use. With cell wear retention time drops drastically. Also you should ensure that SSD uses robust ECC mechanism such as LDPC.
-
My current backup strategy includes writing changed files to the backup SSD and removing deleted files so the content of both volumes is the same, and then creating a hash file of the source, and checking the entire backup with that hash file, so all content and metadata get read on both the source and backup.
In theory this will find (and report) any corrupted sectors on both, and on an SSD, it should force the scrub-on-read operation if a sector is failing.
What happens if a file is deleted or corrupted and you don't notice before a backup occurs? This sounds more like a manual RAID1.
It is like RAID1, but the copy can be kept offline. A better backup system would be to archive changed files after a full backup which is what I used to do, but that is impractical when backing up from one 2TB volume to another 2TB volume, or where there are large changes on the original volume.
In the future I may be backing up my portable 2TB SSDs to my workstation's huge RAID volume instead of other portable 2TB SSDs.
-
Picking up from golden_label's hint:
I run an older OS version on my Raspi3 (which is usually blocked from going online in the router and runs some rather specific local tasks), so I couldn't install the pv command. The Raspi3 only has USB2 ports, so we could run "sudo cat /dev/sda >/dev/null" at about 30MByte/s and wait for 10 hours, while watching CPU load with "htop".
This prompted me to MacGyver an external docking station to a spare headless Raspi4.
Sequence to set things up: - "sudo apt-get update" - "sudo apt-get install pv"
Get things running:
- plug in external drive
- check with "df -h"
- if not mounted, check "sudo fdisk -l"
- run read "sudo pv -ctrabp /dev/sda >/dev/null" <- this is processing an 1TB EVO870 while I am typing these lines. USB2 connection yields 30MByte/s, USB3 ~288MByte/s
Wrapping things up:
- "sync"
- "sudo umount /dev/sda"
- cross fingers that this voodoo worked
Next step: dump that SSD into a file on another drive, then restore from file to another SSD. Would be great if that worked. My doubt is not about Linux dd, but due to my lack of knowledge regarding the various copy protection themes. At any rate, this thread is about figuring out maintaining data retention on SSD's.
Update: pv dumped that 1TB SSD within 50min @ 286MiB/s. Right now I am preparing an HDD to accept the SSD's content.
-
For leaving with no power for long term, you want as minimum cell levels as possible. SLC would be perfect, but not really an option these days. So it should be MLC or at least no worse than TLC. Also it should be a brand new drive or with minimal use. With cell wear retention time drops drastically. Also you should ensure that SSD uses robust ECC mechanism such as LDPC.
ah, if Solid State Drives used ferromagnetic memory, and I had stable data on its implementation, then... I would be willing to invest in SSD/FeRAM
-
I couldn't install the pv command
if you have Gcc&C, you can download the source, configure, and compile, as I did yesterday.
-
DiTBho, good to know, I'll keep that in mind, thanks. Last time I dived so deeply into Linux, was when I had to port drivers to kernel 2.4 for an embedded board that we had designed. Since then I have been a bit out of the loop. I love Linux for low level stuff, like what we are discussing here. Most of the time I run virtual machines. This was the first time I fired up that Raspi4 (which I only got a couple of months ago). I found the USB3 performance delightful.
-
The only large HDD ready at hand is NTFS formatted. NTFS write support is done by a usermode driver: "sudo apt-get install ntfs-3g".
As it turns out, write speed for the Raspi4 from SDD to the NTFS device is about 30MiB/s max, no matter if dd or pv is used. Directly piping through gzip results in an average write speed of about 7MiB/s.
Since this is going to be a long operation, running well over night, I decided to use the full CPU and do both writes at the same time.
Next step is dumping the data back to an SSD, to see if it will work without issues. Again, not exactly what I was looking for, when I started this thread, but maybe a viable workaround for my task at hand.
And incidentally that source SSD gets exercised as a side effect... ;D
-
Alright, what have we learned in this thread?
- Without detailed manufacturer information, we cannot know how an SSD works internally. Therefore our best bet is to make the SSD take a close look at itself and let it figure out the charge levels in its memory cells. This can be done most easily under a Linux environment. Using its USB3 ports, a Raspi4 will read "sudo cat /dev/sda >/dev/null" an Samsung EVO 870 in an Inateck FD1003 docking station at about 288MB/s.
- since we want to read the whole SSD, we can use this opportunity to dump its complete contents into an image file on a regular backup media, in my case large HDD's. Later I wrote the image back and had all copy protections/licenses intact. Image integrity can be checked via a checksum tool, e.g. md5sum or sha256sum.
Data transfer speeds showed large variations:
sudo pv /dev/sda > /mnt/usbhdd/ss_pv.img to an NTFS formatted Seagate 5TB USB HDD: ~30MB/s, with gzip ~7MB/s
sudo pv /dev/sda > /mnt/usbhdd/ss_pv.img to an EXT4 formatted Seagate 2TB USB HDD: ~80..100MB/s (limited by HDD transfer speed), with gzip ~7MB/s(!)
Restore from EXT4 Media:sudo dd if=/mnt/usbhdd/ssd.img of=/dev/sdb bs=10MB conv=noerror,sync status=progress - again, mostly limited by HDD transfer speed to ~88MB/s
Update: md5sum crunched that 1TB image in less than three hours ~123MiB/s. Looks like the HDD speed was the limiting factor.
-
There is a mistake in the dd invocation. One that may destroy your data. This is one of the two primary reasons I so strongly drive people away from using Data Destroyer until actually needed: notorious misunderstanding of tool’s operation and its arguments. dd is a prime example of magical thinking (https://en.wikipedia.org/wiki/Magical_thinking) among *nix folk. Not leading to catastrophes only thanks to lucky coincidences.
The sync in the above invocation is randomly adding runs of zero bytes in data being copied.(1) You might have meant the sync oflag (not conv), but for this bs is wrong. It is specified in megabytes instead of mebibytes. While it will not prevent data from being written, metric units will not be aligned to sector sizes (or erasure block sizes on flash media). That will lead to increased wear and may cause lower performance.(2) But to make bs being respected in a way suitable for sync, one also has use GNU’s dd and its non-standard fullblock iflag. With all these options set correctly, larger block sizes are still preferred to not disrupt storage medium’s internal caches and (in flash) give allocation algorithms some more air. They are not designed to see unneeded, frequent flushes.
I’m not an expert on sotrage technology. Perhaps DiTBho could provide more insight in this end of the issue. I am also expecting I missed half of the problems dd may cause in this scenario.
(1) The technical definition of this flag is padding incomplete blocks of data with zeros before passing them to the write syscall. But without right understanding of kernel handling of specific devices and carefully chosen arguments it becomes random. And it never makes sense in restoring images.
(2) “May” because it’s kernel, not dd, that does the I/O. Kernel’s I/O strategy is likely to provide enough of cushion to make disruptions from dd negligible.
-
Thanks for the warning. Unless I made a typo (see screenshots), these commands led to a functioning Win7 setup, comprising three partions on that SSD. I'd gladly accept any expert input on a better command syntax.
A couple of decades ago I wrote Linux 2.4 kernel drivers. I'd never even try to pretend to understand that OS. All my work is done by reading man pages and then actual operation reports on the internet.
-
You should take into account that while reading SSD you waste its time it could spend on housekeeping. So if you read it all and then turn off, it's worse than just leaving it powered and doing nothing for the same amount of time.
-
Regarding wraper’s message above
(Added after the failure to answer this (https://www.eevblog.com/forum/general-computing/backup-ssd-how-to-keep-data/msg5112366/#msg5112366))
Before following wraper’s advice and risking data loss, it may be worth seeing the exchange in this thread. Pay close attention to relevance of answers to the topic, to what they are being asked about, and to what their claim would entail. The answers give impression of being valid, because they contain facts. But these facts are disconnected from the statements they are supposed to support. — 2023-10-14; the rest is the original post from Friday.
Thanks for the warning. Unless I made a typo (see screenshots), these commands led to a functioning Win7 setup, comprising three partions on that SSD.
Possible. I answered this in the last sentence of the first paragraph.
I'd gladly accept any expert input on a better command syntax.
The entire second paragraph of my message. Of course it’s better to not take the risk of using data destroyer in the first place. :)
One of the things I forgot is, that writing outside of a file system may require invoking BLKFLSBUF ioctl on the target device (e.g. using blockdev --flushbufs). sync forces sending data to the device, but I recall there were some issues with flushing device’s internal buffers, as also mentioned by Jérôme Pouiller (https://stackoverflow.com/questions/49489798/is-running-sync-necessary-after-writing-a-disk-image#answer-49510013). Unfortunately I no longer recall the details and an attempt to refresh my memory with search engines lands me in discussions regarding filesystems, not devices.
You should take into account that while reading SSD you waste its time it could spend on housekeeping. So if you read it all and then turn off, it's worse than just leaving it powered and doing nothing for the same amount of time.
Finally an answer. However, that response suggests that the firmware is doing refreshing 100% of the time, if the SSD is unused. Is this true?
-
Finally an answer. However, that response suggests that the firmware is doing refreshing 100% of the time, if the SSD is unused. Is this true?
What and how it exactly does only manufacturer knows. But it's very unlikely it will do housekeeping while reading large amounts of data since it will reduce performance a lot. And I'm almost sure it won't erase cells to free them for writing another data as it's much slower than just writing. It cannot be 100% of the time as there is only so much to do. But from what I've seen SSD needs to be left alone to do garbage collection and stuff to restore performance after filling it with data. Likely the same with refreshing old data.
-
I am reading that last post and I am not sure, if we’re on the same page.
We are talking about ensuring data is not damaged. How is erasing blocks as a part of housekeeping relevant? Firmware may not do this, it likely will not, but how does that even matter in this topic? Improving future performance is not a part of ensuring already written data remain intact.
Yes, probably only manufacturer knows. Yet you made a statement, which suggests that you know too. Hence my question.
Your assessment regarding doing data-retention housekeeping is right. It’s unlikely firmware will do it. But the opposite scenario is the user doing the same thing actively. You’re trying to tell me, that doing something 100% of time (active) is wasting more time than doing something unknown percentage of time (passive housekeeping). This may only be true if firmware is also doing this around(1) 100% of time, but then you also say that “only manufacturer knows”. Pardon?
(1) Does not need to be exactly 100%: see my note above on why active reading is suboptimal.
-
I am reading that last post and I am not sure, if we’re on the same page.
We are talking about ensuring data is not damaged. How is erasing blocks as a part of housekeeping relevant? Firmware may not do this, it likely will not, but how does that even matter in this topic? Improving future performance is not a part of ensuring already written data remain intact.
It's relevant in a way that data is refreshed by writing it to another place. And SSD does it's internal data shuffling when idle. How firmware does not do this? Unlike with HDD, system does not really know what is stored where. SSD does all of it's data shuffling like wear leveling and garbage collection internally. Data allocation that system sees has nothing to do with what actually happens inside SSD.
-
Restore from EXT4 Media:sudo dd if=/mnt/usbhdd/ssd.img of=/dev/sdb bs=10MB conv=noerror,sync status=progress - again, mostly limited by HDD transfer speed to ~88MB/s
I actually got better performance backing up an SSD to a modern hard drive rather than to an identical SSD. The Crucial MX500 SSDs that I use, and the Samsung EVO 270 that I tested, drop to about 120 MB/s during continuous writes while the hard drives that I have manage almost 200 MB/s. I may end up using my workstation RAID to backup my portable SSDs because it is so much faster.
-
You should take into account that while reading SSD you waste its time it could spend on housekeeping. So if you read it all and then turn off, it's worse than just leaving it powered and doing nothing for the same amount of time.
Finally an answer. However, that response suggests that the firmware is doing refreshing 100% of the time, if the SSD is unused. Is this true?
Unless the manufacturer says otherwise, I would assume that the only idle-time housekeeping performed is flushing SLC buffers to multi-level cell storage and erasing empty blocks. The idea behind reading the entire contents is to force scrub-on-read operations.
-
Unless the manufacturer says otherwise, I would assume that the only idle-time housekeeping performed is flushing SLC buffers to multi-level cell storage and erasing empty blocks. The idea behind reading the entire contents is to force scrub-on-read operations.
It does not work like this. Phisical block size is like 1MiB - 24MiB which is way larger than logical block. Without shuffling the data, SSD can run out of memory very fast on some use cases.
-
In my book, the experiment is the base for science. Since I don't have any manufacturer information regarding the internals of the SSD, I observe a black box with tools available to me. I thank you all for the hints you shared. Let me in return share my findings:
Copy SSD to an image file: sudo pv /dev/sda > /mnt/usbhdd/ssd_c_2310081711_pv.img
Calculate md5 of that image: time sudo md5sum /mnt/usbhdd/ssd_c_2310081711_pv.img
Result -> ef82749208b7a95f36517c980fa95555
Read blocksizes of the devices involved, i.e.: stat /dev/sdb
Write image back to the SSD: sudo dd if=/mnt/usbhdd/ssd_c_2310090820_pv.img of=/dev/sdb status=progress bs=4096
Calculate md5 of the SSD: time sudo md5sum /dev/sdb
md5 of SSD and image match.
-
bah, it doesn't make sense to hash the entire disk image: if it matches, ok, otherwise you don't know "WHAT?" got corrupted!
It makes more sense to develop software that hashes every single file, and then checks every single file by mounting the image in loopback.
This is how it works the software I developed for my NAS, and that's because I can't afford filesystems { ZFS-*, BTrfs, ...} that do the same at a low level
I have implemented it in order to prevent the risk of "bit flips", as, talking about HDDs, beyond physical damages of { plates, flying read/write hears, motor, pcb, connector, air-filter, ...}, there’s another threat to the files stored on hard disks: small, silent bit flip errors often called data corruption or "bit rot".
"Bit rot errors" occur when individual bits in a stream of data in files change from one state to another (positive or negative, 0 to 1, and vice versa).
I talked about HDDs, but these errors can also happen to flash storage systems (SSD) at rest, or be introduced as a file is copied from one hard drive to another.
-
Unless the manufacturer says otherwise, I would assume that the only idle-time housekeeping performed is flushing SLC buffers to multi-level cell storage and erasing empty blocks. The idea behind reading the entire contents is to force scrub-on-read operations.
It does not work like this. Phisical block size is like 1MiB - 24MiB which is way larger than logical block. Without shuffling the data, SSD can run out of memory very fast on some use cases.
The largest ones I could gain access to now use 1MB blocks with 128 pages. The datasheets for anything larger are behind NDAs.
-
It makes more sense to develop software that hashes every single file, and then checks every single file by mounting the image in loopback.
That is what I do now. So far the only SSD I have used which produced bad data was a Samsung EVO 970 or 980.
More often I get data corruption from network cards until I disable their hardware checksum acceleration. I think my old non-ECC Intel 870 system is also generating errors, but I just retired it.
-
In my book, the experiment is the base for science. Since I don't have any manufacturer information regarding the internals of the SSD, I observe a black box with tools available to me. I thank you all for the hints you shared. Let me in return share my findings:
IMO you did everything right,(1) though note that the experiment does not confirm this. :D
It's relevant in a way that data is refreshed by writing it to another place.
I do not like being taken for and idiot. Neither I like wasting my time on silly arguing like this. But here people’s data safety is at stake.
I can’t read your mind, so perhaps either you are expressing your ideas poorly or I am completely misreading it, but from my subjective perspective the situation looks as follows.
In the other thread you made a statement (https://www.eevblog.com/forum/general-computing/ssd-vs-hdd-for-data-security/msg5075539/#msg5075539), nature of which requires both deeper knowledge on firmware’s operation and providing a specific technial information. Despite being asked to clarify, you never shown you know either.(2) In this thread you deliver an even narrower version of the same statement (https://www.eevblog.com/forum/general-computing/backup-ssd-how-to-keep-data/msg5110485/#msg5110485), which is one step from plunging into the abyss of absurdity. Instead of explaining you engage in delivering claims, that are likely true in separation, but disconnected from what they are mean to support.
So, could you please stay in the context of your own statement and this thread? And deliver explanation that is relevant to what you claim? Because so far my impression of the situation is very bad. :(
(1) Of course I should whine about using dd once again, but one person can’t safe the world. I count removal of the data-destroying conv a success.
(2) And I did not ask for authoritative information. Personal experience and reports from other people are fine too, as long as the reader has no doubts about the answer being honest. This condition can no longer be met, but in the other thread it was different.
-
What isn't clear in what I said? SSD can only refresh data by writing it to another free location. It's not an effing DRAM or something. Moving the data and erasing free space for it's internal purposes generally happens when it's idle to not degrade performance.
-
That is what I do now
yup, that's the right way.
What do you use? Custom software, or an already existing solution?
More often I get data corruption from network cards until I disable their hardware checksum acceleration
Ummm, it sounds kernel bug. I had a similar issue with Jumbo frames & chk offloading on a Tulip quad-ethernet 10/100Mbps network card made by Digital in 2001.
"jumbo frames" have NON-standard length and the circuit that generated the checksum had not been reconfigured correctly, so a couple of bytes were eaten every now and then, the payload passed intact, but the checksum every now and then was done on a smaller block short, so it was wrong, no problem for UDP/IP, but for TCP/IP that was a random discard, go-back n, and the "error rate" was very high.
5 lines of C. Problem solved. 15 bloody weeks to figure it out!
At first I thought it was faulty hardware (as it's second hand, ex corporate stuff), so I bought 4 other network cards, which I assure you are not small, they are very long and take along the entire length of the PCI slot.
All 4 showed the same defect. At that point I started looking in the kernel :o :o :o
-
SSD can only refresh data by writing it to another free location
yup, I can confirm this, and add that "Bit rot errors" can occur.
It doesn't necessarily happen, but it can happen, and it would be best to keep this in mind.
-
That is what I do now
yup, that's the right way.
What do you use? Custom software, or an already existing solution?
I mostly run Windows so use the Hashcheck extension to File Explorer. It can generate hash files for entire directory structures or an entire volume. On SSDs it will hash multiple files at once and completely saturate the CPU. Unfortunately it does not do this with RAID which is not reported as an SSD because Windows' SSD detection is broken, has always been broken, and based on history, will remain broken. I think this is because Microsoft prefers that users rely on their Cloud storage services, so they deliberately cripple their OS to make local storage perform worse.
More often I get data corruption from network cards until I disable their hardware checksum acceleration
Ummm, it sounds kernel bug. I had a similar issue with Jumbo frames & chk offloading on a Tulip quad-ethernet 10/100Mbps network card made by Digital in 2001.
It comes up sometimes with Realtek, especially their older hardware, and always with ASIX (USB to Ethernet), which is just broken.
"jumbo frames" have NON-standard length and the circuit that generated the checksum had not been reconfigured correctly, so a couple of bytes were eaten every now and then, the payload passed intact, but the checksum every now and then was done on a smaller block short, so it was wrong, no problem for UDP/IP, but for TCP/IP that was a random discard, go-back n, and the "error rate" was very high.
I stopped using Jumbo Frames. My hardware cannot saturate my network anyway, although it comes close, and Jumbo Frames does not provide any measurable advantage for me.
5 lines of C. Problem solved. 15 bloody weeks to figure it out!
At first I thought it was faulty hardware (as it's second hand, ex corporate stuff), so I bought 4 other network cards, which I assure you are not small, they are very long and take along the entire length of the PCI slot.
All 4 showed the same defect. At that point I started looking in the kernel :o :o :o
Reading through the FreeBSD notes about network cards show that hardware bugs are often fixed with better drivers, but sometimes it is necessarily to forgo problematical features. Hardware checksum offloading does not provide much performance advantage anymore, at least at 1 gigabit speeds.
My old Intel 870 system managed to create a hash file showing corruption before the data was transferred over the network, so I am sure something is wrong with it. The problem could have been a bad disk, but the storage volumes were either RAID or Windows Storage Spaces.
-
Link your external SSD or hard drive to your computer so that it can be used as a backup. By right-clicking on the internal disk you want to backup in the Navigation Pane on the left and choosing Properties, you can confirm that your external HDD or SSD has the same capacity as or more than the internal drive.