Rsync se nezastaví na chybě

[RDa]

Ahoj, kopiruji data z USB SSD ktere neni v nejlepsim stavu, a po ruznych pokusech jsem zjistil ze kdyz se kopiruji pomalu, tak to vykazuje mene chyb. Tu pomalost jsem dostahl pres rsync --bwlimit option, ale pak kdyz dojde k chybe, tak to rsync vesele ignoruje a kopiruje same nuly.

Jak rict rsyncu, aby pri "read error" skoncil ? (napr. mc ve stejnem pripade o chybe vi a zastavi se)

Cely prikaz je:

Kód: [Vybrat]

rsync -ai --progress --partial --append --bwlimit=1000 /mnt/usb/neco/ /mnt/sata/neco

A chyba disku takhle:

Kód: [Vybrat]

Jan 04 05:26:51 [kernel] sd 10:0:0:0: Device offlined - not ready after error recovery
Jan 04 05:26:51 [kernel] sd 10:0:0:0: rejecting I/O to offline device

Jde o exfat (s kernel driverem).

Ze tam je chyba nejakym zpusobem musi rsync vedet, protoze od tech cca 5:26 jsou vsechny poskozene soubory s aktualnim create/modify date, zatimco pred tim selhanim blokoveho zarizeni rsync prenastavil timestampy podle zdroje. Takze jsem nastesti mohl identifikovat a odstranit ty falesne data.


Celej log:

Kód: [Vybrat]

Jan 04 04:25:01 [kernel] usb 2-7: reset SuperSpeed Plus Gen 2x1 USB device number 23 using xhci_hcd
Jan 04 04:25:01 [kernel] sd 10:0:0:0: [sdd] tag#0 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK cmd_age=30s
Jan 04 04:25:01 [kernel] sd 10:0:0:0: [sdd] tag#0 CDB: Read(16) 88 00 00 00 00 00 0a 0f a4 00 00 00 01 00 00 00
Jan 04 04:25:01 [kernel] I/O error, dev sdd, sector 168797184 op 0x0:(READ) flags 0x80700 phys_seg 16 prio class 0
Jan 04 05:01:01 [CROND] (root) CMD (run-parts /etc/cron.hourly)
Jan 04 05:01:01 [CROND] (root) CMDEND (run-parts /etc/cron.hourly)
Jan 04 05:25:23 [kernel] usb 2-7: reset SuperSpeed Plus Gen 2x1 USB device number 23 using xhci_hcd
Jan 04 05:25:23 [kernel] sd 10:0:0:0: [sdd] tag#0 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK cmd_age=30s
Jan 04 05:25:23 [kernel] sd 10:0:0:0: [sdd] tag#0 CDB: Read(16) 88 00 00 00 00 00 0b 3a a3 00 00 00 02 00 00 00
Jan 04 05:25:23 [kernel] I/O error, dev sdd, sector 188392192 op 0x0:(READ) flags 0x80700 phys_seg 9 prio class 0
Jan 04 05:25:53 [kernel] usb 2-7: reset SuperSpeed Plus Gen 2x1 USB device number 23 using xhci_hcd
                - Last output repeated 4 times -
Jan 04 05:26:51 [kernel] sd 10:0:0:0: Device offlined - not ready after error recovery
Jan 04 05:26:51 [kernel] sd 10:0:0:0: [sdd] tag#0 FAILED Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK cmd_age=88s
Jan 04 05:26:51 [kernel] sd 10:0:0:0: [sdd] tag#0 CDB: Read(16) 88 00 00 00 00 00 0b 3a a3 00 00 00 00 08 00 00
Jan 04 05:26:51 [kernel] I/O error, dev sdd, sector 188392192 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Jan 04 05:26:51 [kernel] sd 10:0:0:0: rejecting I/O to offline device
Jan 04 05:26:51 [kernel] I/O error, dev sdd, sector 188392704 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0
Jan 04 05:26:51 [kernel] I/O error, dev sdd, sector 188392192 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Jan 04 05:26:51 [kernel] I/O error, dev sdd, sector 188392448 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Jan 04 05:26:52 [kernel] I/O error, dev sdd, sector 188392960 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
Jan 04 05:26:52 [kernel] I/O error, dev sdd, sector 188392960 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Jan 04 05:26:52 [kernel] I/O error, dev sdd, sector 188393472 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
Jan 04 05:26:52 [kernel] I/O error, dev sdd, sector 188393472 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Jan 04 05:26:52 [kernel] I/O error, dev sdd, sector 188393984 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
Jan 04 05:26:52 [kernel] I/O error, dev sdd, sector 188393984 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Jan 04 05:26:57 [kernel] blk_print_req_error: 32 callbacks suppressed
Jan 04 05:26:57 [kernel] I/O error, dev sdd, sector 188402688 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
Jan 04 05:26:57 [kernel] I/O error, dev sdd, sector 188402688 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Jan 04 05:26:57 [kernel] I/O error, dev sdd, sector 188403200 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
Jan 04 05:26:57 [kernel] I/O error, dev sdd, sector 188403200 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Jan 04 05:26:57 [kernel] I/O error, dev sdd, sector 188403712 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
Jan 04 05:26:57 [kernel] I/O error, dev sdd, sector 188403712 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Jan 04 05:26:57 [kernel] I/O error, dev sdd, sector 188404224 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
Jan 04 05:26:57 [kernel] I/O error, dev sdd, sector 188404224 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Jan 04 05:26:58 [kernel] I/O error, dev sdd, sector 188404736 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
Jan 04 05:26:58 [kernel] I/O error, dev sdd, sector 188404736 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Jan 04 05:27:02 [kernel] blk_print_req_error: 30 callbacks suppressed


[Reklama]

[Filip Jirsák]

Pro kopírování dat z poškozených médií je lepší ddrescue. Ve vašem případě je pravděpodobné, že rsync ta chybná data dostává od něčeho před sebou, tipoval bych řadič toho USB disku.

[RDa]

Pro kopírování dat z poškozených médií je lepší ddrescue. Ve vašem případě je pravděpodobné, že rsync ta chybná data dostává od něčeho před sebou, tipoval bych řadič toho USB disku.

V tomto pripade lepsi neni, protoze s timto konkrektnim kousem nemate zkusenost. dd-rescue vyhnije rovnou kolem sektoru 1700, protoze ten uz radic disku neprecte a disk se odpoji. A delat fyzicke odpojeni a pripojeni bych fakt nechtel delat pri kazde chybe kterou ddrescue potka. Obnovoval jsem stovky tera a vim co kdy pouzit, o to nemejte obavy.

Klasickym kopirovanim se ziskalo uz 2T z 3T obsahu (na 4T disku), protoze novejsi data precist slo, a rucni intervence s odpojenim a pripojenim kabelu byly na unosne mire. Starsi soubory tam vykazuji caste resety (radic premysli/pokousi se dele nez mu linux toleruje), ale pak nastane situace kdy FW crashne a pak uz se ani nenecha resetovat USB (pak je to tvrde nedostupne pro jakekoliv I/O).

Ty nuly nepochazi z radice - protoze disk je offline, a jak jsem psal, midnight commander ve stejnem pripade napsat ze zdrojovy soubor je necitelny a mohl jsem ponechat nebo smazat cil a tim to koncilo.

Ale rsync je proste divny nastroj - neverim tomu ze nekontroluje navratove kody z fopen/fread a tupe nakopiruje nuly.
^^ a tohle je to co resim, tak se prosim drzte tematu

[Michal Šmucr]

Netuším, jak přesně se chová rsync při kopírování z toho konkrétního zařízení. To že to neskončí chybou a kopíruje nuly rozhodně není košér. Nezměnilo by tam přidání parametru timeout, kdy mu přidáš nějaký časový limit - nevím vteřina - pro získání konkrétního souboru? Pokud při tom read requestu to blokové zařízení nějak váhá, tak by to možná mohlo něco hodit.

Jinak ještě mimoběžně. jediné, co mi trochu vysvětluje, proč by mělo projít kopírování, ale ddrescue selže takhle brzy, je to, že si při sekvenčním kopírování všech bloků FS hrábne na nějakou oblast, kde sice nejsou reálně není žádné alokované soubory, ale SSDčko se z toho přístupu už nevzbelhá.
Já už párkrát používal ddrescue dohromady s partclone - primárně aby netrávil čas zbytečnými opakováními při čtení z oblastí, kde nejsou užitečná data. Pokud je čitelná alokační tabulka, tak partclone vytvoří mapu alokovaných oblastí, a ddrescue pak ignoruje zbytek.
S exfatem a omezením rychlosti čtení u ddrescue by to mohlo být něco jako..

partclone.exfat --domain -s /dev/partition -o /tmp/partition.domain
ddrescue --max-read-rate=$((1024*1024)) --domain-mapfile=/tmp/partition.domain /dev/partition /tmp/image
mount -o loop /tmp/image /mnt/tmp

I když vím, že jestli už máš zachráněno větší část dat rsyncem, tak to možná nebude dávat úplně smysl, krom zkoušky s více možnostmi čtení a chování při chybě, co nabízí ddrescue oproti rsyncu.
Další možnost s ddrescue je - udělat si seznam zbývajících souborů ke zkopírování (třeba rsyncem s dry run), pak případně vytvořit cílovou adresářovou strukturu a finálně to protáhnout smyčkou ve skriptu nebo xargs, co bude pro každé kopírování souboru volat ddrescue s parametry.

[Michal Šmucr]

Jak to nakonec dopadlo? Podařilo se ti nakonec přesvědčit ten rsync, aby to dokopíroval bez nulového obsahu souborů? Snad to SSD nezdechlo úplně..

Když jsem o tom ještě přemýšlel po tom, co jsem poslal poslední post, tak bych to osobně asi zkusil udělat tou poslední zmíněnou variantou, rsyncem udělat jen seznam souborů, které chybí, a pak vlastní skript, co by kopíroval jednotlivé soubory pomocí ddrescue. Mohl bych tam totiž přidat do toho cyklu i nějaký automatický mechanismus, který by reagoval na chybu kopírování aktuálního souboru (podle návratového kódu z ddrescue), zkusil by to párkrát zopakovat a mezi tím by mohl dělat něco s USB zařízením ( třeba power cycle toho konkrétního portu pomocí uhubctl https://github.com/mvp/uhubctl ), což by mohlo ušetřit i to manuální odpojování a připojování.

[Reklama]

[RDa]

Dopadlo to tak, ze jsem si to cele oskriptoval sam.

Takze mam jeden skript co analyzuje soucasnou situaci mezi zdrojem a cilem (z pohledu velikosti souboru a timestampu), a pak to vyprodukuje seznamy serazene podle nazvu, velikosti a casu, plus seznam pro castecne soubory, vcetne statusu:

Kód: [Vybrat]

# ./syncer.php | tail -n 3
[count] same=14018 timediff=0 sizediff=2 todo=1550
[bytes] same=2071684139183 timediff=0 sizediff=(1678033637:1015545856)=662487781 todo=929056391920 max=19025802592
[MiBsz] same=1975711 timediff=0 sizediff=(1600:968)=631 todo=886017 max=18144

Jiny skript pak umi cist ty vytvorene seznamy a bud pusti cp nebo rsync, a preskakuje existujici soubory (v pripade rsync ho pusti i na neuplne). Nyni preferuji rsync protoze umi pokracovat v tech partialech (ktere se obcas tvori moji intervenci a la Ctrl+C) a pak ma samozrejme riditelnost rychlosti. Ten rsync se pusti vzdy jenom na 1 soubor, a po skonceni rsynce tam mam kontrolu zda aktualni cil nahodou neobsahuje na konci same nuly (4KiB), takze by se smycka ukoncila a ja videl rano zda a na cem to selhalo - pak stacilo nalezt odkud jsou nuly, udelat truncate --size a pokracovat rsyncem.

Se seznamy muzu delat pak co chci, nez je zacnu prenaset, coz pomaha prioritizovat urcite soubory nebo volit strategii (jel jsem vcera od nejmensich souboru po nejvetsi, pak u nocnich behu preferuji od nejnovejsich po nejstarsi - abych maximalizoval uspesnost kdy to nehlidam, pripadne je muzu rozdelit grepem nez to pustim paralelne).

Nyni mam pusteny dve vlakna nad seznamy pro ruzne slozky a oba maj limit 2500 KB/s, takze to leze cca 5MB/s. Rucni adhoc kopirovani jsem resil vedle v mc, ale kdyz vidim ze se to zastavi tak musim dat abort, at se ten radic prilis netrapi, ale dokazal jsem nahnat nejakych par GB jeste.

Odpoledne to vypadalo ze jeste 48 hodin, pokud vse dobre dojede:

Kód: [Vybrat]

# while true ; do echo -n `date` '' ; ./syncer.php | tail | grep MiB ; sleep 3600 ; done
Sun Jan 5 05:05:10 PM CET 2025 [MiBsz] same=2035446 timediff=0 sizediff=(640:297)=343 todo=827242 max=18144
Sun Jan 5 06:05:10 PM CET 2025 [MiBsz] same=2052923 timediff=0 sizediff=(2048:282)=1765 todo=808357 max=18144
Sun Jan 5 07:05:11 PM CET 2025 [MiBsz] same=2070273 timediff=0 sizediff=(3072:373)=2699 todo=789983 max=18144
Sun Jan 5 08:05:11 PM CET 2025 [MiBsz] same=2084967 timediff=0 sizediff=(4608:3067)=1541 todo=773753 max=18144
Sun Jan 5 09:05:12 PM CET 2025 [MiBsz] same=2101610 timediff=0 sizediff=(6592:3860)=2732 todo=755126 max=18144
Sun Jan 5 10:05:12 PM CET 2025 [MiBsz] same=2120478 timediff=0 sizediff=(5596:2298)=3298 todo=737254 max=18144
Zrejme bych to zvladl i na blokove urovni podobne jako byl tvuj navrh, protoze jak mam ctecku exfat-u, tak presne vim ktere sektory co obsahuji, a mohl bych to tahat do sparse file nebo derave cache kopie. Puvodne jsem to chtel udelat, pro metadata, ale myslim ze zadna chyba na tom FS neni kterou bych musel opravovat - takze me to uz v teto fazi nic neprinese.

Disk ma fakt problem pod zatezi, treba za noc (12hodin cca) se objevila jen 4x ta soft chyba kdyz to slo 5MB/s ... a neodpojilo se to. Takze to necham dojet - a vsude kde jsem chyby zahledl tak ty video soubory prehrat opravdu sli, bez nejakeho glitche.. predpokladam tedy ze data zkoruptena nebudou.

Pripojeny to je v 10G rezimu, jsem linej shanet A-C kabel, nebo A-C/C-C s usb2 only, zda to neblbne kvuli USB samotnemu. Ale vzhledem k tomu ze nedavno nahrana data slo stahnout plnou rychlosti, a problem je zejmena u starsich.. tak bych rekl ze to bude problem na opacnem konci - smerem do flashek nebo ve FW.

[RDa]

... ( třeba power cycle toho konkrétního portu pomocí uhubctl https://github.com/mvp/uhubctl ), což by mohlo ušetřit i to manuální odpojování a připojování.

Se mi podle odkazu zda ze to funguje jen s hubama, a kdyz mam jediny Type-C port na desce, tak to nebude fungovat?

V dmesg se totiz objevovalo attempt power cycle:

Kód: [Vybrat]

[120146.136098] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[120151.768091] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[120151.976031] usb 2-7: device not accepting address 37, error -62
[120151.985187] usb usb2-port7: attempt power cycle
[120159.448095] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[120165.080089] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command

Ale nic se nedelo - vyresil to pouze rucni zasah.

Deska je to tahle, Type-C port je zrejme z Q670E chipsetu: https://www.kontron.com/en/products/k3833-q-mitx/p176291

[Michal Šmucr]

Dopadlo to tak, ze jsem si to cele oskriptoval sam.

Takze mam jeden skript co analyzuje soucasnou situaci mezi zdrojem a cilem (z pohledu velikosti souboru a timestampu), a pak to vyprodukuje seznamy serazene podle nazvu, velikosti a casu, plus seznam pro castecne soubory, vcetne statusu:
...
Odpoledne to vypadalo ze jeste 48 hodin, pokud vse dobre dojede:

Disk ma fakt problem pod zatezi, treba za noc (12hodin cca) se objevila jen 4x ta soft chyba kdyz to slo 5MB/s ... a neodpojilo se to. Takze to necham dojet - a vsude kde jsem chyby zahledl tak ty video soubory prehrat opravdu sli, bez nejakeho glitche.. predpokladam tedy ze data zkoruptena nebudou.

Bezva, byl jsem zvědavý. Držím palce, ať to dojede a je tam co nejmíň porušených souborů.
To je asi poprvé, co vidím použití PHP mimo web (nebo nějakou správu web projektů).

Pripojeny to je v 10G rezimu, jsem linej shanet A-C kabel, nebo A-C/C-C s usb2 only, zda to neblbne kvuli USB samotnemu. Ale vzhledem k tomu ze nedavno nahrana data slo stahnout plnou rychlosti, a problem je zejmena u starsich.. tak bych rekl ze to bude problem na opacnem konci - smerem do flashek nebo ve FW.

Jo taky si podle popisu nemyslím, že by to tím bylo. Měl jsem před pár lety podobný problém s nějakým SATA SSD Crucial, co známý vyndal z notebooku. Ta pravděpodobnost přečtení souborů se měnila podle stáří a taky jsem brzdil rychlost, ale nedělal jsem to rsyncem, ale přes cgroups pravidlem na blokové zařízení. Nakonec z toho chtěl tak 15% prioritních souborů, z toho pak většina prošla. Po kopírování jsem na SSD zkoušel ještě blkdiscard, jestli se nevzbelhá, ale šlo do koše.

Se mi podle odkazu zda ze to funguje jen s hubama, a kdyz mam jediny Type-C port na desce, tak to nebude fungovat?

V dmesg se totiz objevovalo attempt power cycle:

Kód: [Vybrat]

[120146.136098] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[120151.768091] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[120151.976031] usb 2-7: device not accepting address 37, error -62
[120151.985187] usb usb2-port7: attempt power cycle
[120159.448095] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[120165.080089] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command

Ale nic se nedelo - vyresil to pouze rucni zasah.

Deska je to tahle, Type-C port je zrejme z Q670E chipsetu: https://www.kontron.com/en/products/k3833-q-mitx/p176291

Hmm.. to vypadá, že ten USB-C port pravděpodobně opravdu neumí PPPS, přestože to inzeruje. Chodí to někdy i s interními HUBy na desce, třeba můj starý Intel Z77 (kancl PC) to uměl v pohodě. Novější Haswell to na interních portech nedává.
Ale mám pod tím doma downstream externí HUB Axagon HUE-F7A z Alzy, kde to jde v pohodě i selektivně na jednotlivých portech.
Pak mám ještě USB 3.0 HUBy z Amazonu, modely které jsou explicitně zmíněny jako kompatibilní a testované. Kdyby ti to nějak pomohlo, můžu ti je určitě půjčit. Ale má to jen klasický modrý 5Gbps A konektor.

[RDa]

To je asi poprvé, co vidím použití PHP mimo web (nebo nějakou správu web projektů).

Ja pouzivam PHP v CLI na hodne veci (vse na co je primitivni bash skript kratkej), od ucetnictvi a samo-domo ERP k reseni vyroby elektroniky az po obrazove a video kodeky, filesystemy, rozebirace vsemoznych binarek a nebinarek, virtualky na 8 bity, simulace, a veci ktere me ted nenapadnou. Pres http je prakticky nic.. jen jedna "appka" na skladove zasoby skrze QR kody tam smeruje pro sve UI.

Dalsi stupen uz je C, a to musi mit opodstatneni, aby se clovek trapil o neco vice s kodem. Ono to je nakonec jedno, zda perl/python (ktere neumim a ucit se uz nebudu) nebo PHP ... hlavne u me jeste k tomu vsemu nerad pouzivam 3rd party kod, takze mam vlastni privatni a ciste piskoviste.

[Michal Šmucr]

Ja pouzivam PHP v CLI na hodne veci (vse na co je primitivni bash skript kratkej)

To je originální a veskrze pragmatický přístup, pokud tě to neomezuje (třeba rychlost u těch kodeků) a navíc máš evidentně hromadu existujícího kódu, tak samozřejmě proč ne. Koneckonců vlastně i do PHP se dá napsat rozšíření v C.
U mě je ten další stupeň za shellem Python nebo na Windows pak Powershell (kde se dají používat i .NET objekty a třídy, takže na takové Win specifické věci to občas pomůže), ale povětšinou jsou to bastly pro interní použití (nástrojárna .

[Jan Fikar]

Jenom takový kontrolní dotaz: ten disk asi nemá SATA? U chcíplých disků fungovalo SATA + ddrescue daleko lépe a rychleji, než USB s tím stálým USB reset ...

Jestli jediná možnost je USB, tak ještě možná dokáže USB port (je to XHCI?) resetovat toto:

Kód: [Vybrat]

echo -n 0000:04:00.0 | sudo tee /sys/bus/pci/drivers/xhci_hcd/unbind
sleep 5
echo -n 0000:04:00.0 | sudo tee /sys/bus/pci/drivers/xhci_hcd/bind

kde to 0000:04:00.0 je PCI adresa toho USB řadiče, teda z lspci

[Michal Šmucr]

Ten unbind, bind na USB by se možná vyzkoušet dal. Ale je otázka, jestli to na konkrétním zařízení pomůže, protože to většinou neresetuje interní firmware. Ten výtuh při čtení typicky vznikne tak, že SSD má požadavky ze systému v interní frontě IO operací a ty se neprovedou, protože to čeká na tu flash stranu, kde se to podle FTL mapy skládá z více čipů (je tam proklad), některý z nich "váhá" a v podstatě to celé vymrzne. Když se zařízení fyzicky odpojí a připojí nebo se vypne napájení, tak firmware naběhne celý znovu s prázdnou frontou IO operací z hosta a dá se to případně zkusit znovu. Aspoň takhle se to většinou tvářilo mě v podobných situacích, když jsem zkoušel třeba soft reset SATA portu (delete a rescan přes procfs) vs. přerušení napájení/odpojení v UASP USB externí škatuli.

Mimo to některé operace na pozadí (odlišné od běžného host IO) jsou pak často v persistentní frontě, to je případ třeba blkdiscard (trim, unmap z hosta), garbage collection. U nich pak reset nic neřeší, firmware si po nějaké době po startu načte frontu a pokračuje tam, kde předtím skončil. Což je třeba důvod toho, že pokud někdo na SSD omylem smázne data nebo zruší partišny a má v OS zapnuté trimování, které to pošle do zařízení, tak ho většinou nezachrání ani rychlé odpojení SSD nebo vypnutí počítače. Jakmile firmware SSD znovu naběhne, klidně i v jiném počítači, tak dokončí operace z fronty a z těch oblastí už se dají přečíst jen nuly.

Ale je to asi relativně jednoduché otestovat, jestli to v tomhle případě pomůže.

[RDa]

Jenom takový kontrolní dotaz: ten disk asi nemá SATA? U chcíplých disků fungovalo SATA + ddrescue daleko lépe a rychleji, než USB s tím stálým USB reset ...

SATA mit nemuze kvuli rychlosti - je to USB Gen2x2 (2x10Gb/s), mohlo to byt NVMe, ale ani to to neni, viz interni jednocipova konstrukce:

https://www.techpowerup.com/review/kingston-xs2000-2-tb/2.html

SMART je celkem rozbitej (ale ukazuje neco pres -d sat), mozna jen kvuli tomu ze jedu USB mass storage, protoze UASP driver to podivne chovani disku nedaval (a mel jsem podezreni na typicky UASP bugy ve fw, tak to bylo prvni co jsem oquirkoval).

[Jan Fikar]

NVMe jsem zatím nezachraňoval, ale SMART již u nich není to co to bývalo u HDD nebo SDD.