Rich, I was afraid of that. I am getting errors trying smartmontools with the sata to usb interface from best buy. System file corruption is a possible cause of the 0xc000021a stop code that was indicated. I need to look at the drive adapter and see if I can identify the chip that was used. Is it unlikely to be the ssd if I've copied it without any errors and a consistent read speed? What is your favorite rescue image? Debian cinnamon is not starting but I don't have any read write volume in the sytem.
On Mon, Feb 26, 2024 at 8:50 AM Rich Pieri <richard.pi...@gmail.com> wrote: > On Mon, 26 Feb 2024 01:30:55 -0500 > John Hall <johnhall...@gmail.com> wrote: > > > Ok So this is odd. I figured I'd look. dd is cpu bound ! WEIRD! > > 104909 root 20 0 6628 1248 756 R 73.2 0.0 228:02.10 > > mount.ntfs > > 105003 root 20 0 5540 96 0 S 32.5 0.0 > > 101:36.29 dd And mount.ntfs taking more cpu than dd! Wow. That is > > surprising, and ridiculous. > > Not really. The NTFS driver is a FUSE module and it is very much CPU > bound. If the partition is encrypted then that's more CPU needed. > > Regarding scrubbing sensitive data: unfortunately for you, the only way > to reliably do that on flash-based SSDs is to issue the ATA secure > erase command which will zero out the whole drive. But if the > partitions are encrypted then throwing away the keys (clear/reset TPM > for bitlocker keys) should be sufficient for most use cases. > > -- > \m/ (--) \m/ > _______________________________________________ > Discuss mailing list > Discuss@lists.blu.org > http://lists.blu.org/mailman/listinfo/discuss > _______________________________________________ Discuss mailing list Discuss@lists.blu.org http://lists.blu.org/mailman/listinfo/discuss
