gene heskett composed on 2024-01-16 20:08 (UTC-0500):
> Felix Miata wrote:
>> I straightened out the wrapping mess, and gave each entry a line number. I
>> see
>> nothing I recognize as representing serial number duplication among /dev/sdX
>> (physical device) names:
>> /dev/sda 9 /dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V
>> /dev/sdd 19 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V
>> /dev/sde 28 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E
>> /dev/sdf 36 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T
>> /dev/sdg 43 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W
>> /dev/sdh 51 /dev/disk/by-id/ata-Gigastone_SSD_GSTD02TB230102
>> /dev/sdi 53 /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146
>> /dev/sdk 55 /dev/disk/by-id/ata-Gigastone_SSD_GSTG02TB230206
>> Exactly which line numbers represent duplication among the physical drives?
> lsblk, which I've published several times, shows 5 drives. by-id listing
> only shows 3. The drive I've been trying to use bounces from /dev/sdd to
> sde to sdh dependin on which controller it is curently plugged into.
>From your 2024-01-15 17:56 -0500 post, I see 8 unique serial numbers from SATA
SSDs, 5 Samsung, 3 Gigastone.
I ignore all your posts with lsblk that didn't use the -f option to facilitate
identifying individual SSDs.
> And I've since tried cp in addition to rsync, does the same thing,
> killing the sysytem with the OOM but much quicker. cp using all system
> memory (32Gb) in 1 minute, another 500K into swap adds another 15 secs,
> and the OOM kills the system. So both cp and rsync act broken.
> rsync, with a --bwlimit=3m set, takes much longer to kill the system but
> the amount of data moved is very similar, 13.5G from clean disk to
> system freeze for rsync, 13.4G for cp.--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata
