Dotaz: SSD - vadný superblok

[Petr Fiedler]

Zdravím,

z ničeho nic mi dnes vytuhnul systém. Musel jsem jej natvrdo vypnout. Pak už nebootoval. Nahodil jsem jiný OS a na EFI pustil fsck.fat. Program mi oznámil, že je tam dirty flag a jestli jej chci smazat. Nesmazal jsem jej, ale protože systém stále nebootoval, tak jsem jej nakonec smazal. Systém stále nebootoval a tak jsem si řekl, že jej obnovím Clonezillou. Ta disk neviděla a psala něco o špatném superbloku. Na disku jsem tedy vytvořil novou tabulku oddílů gpt a naformátoval jej na ext4. Disk ale stále zlobil a tak jsem gpt + ext4 vytvořil znovu, ale stále zlobil. Sám se odpojoval a zase připojoval. Pustil jsem na něj fsck.ext4 a dostal jsem výpis viz. níže, ve kterém stojí, že je něco se superblokem. Zkusil jsem i jiné velikosti dle rady programu, ale se stejným výsledkem. Půjde s tím prosím něco udělat?

~$ sudo fsck.ext4 /dev/sdb
e2fsck 1.45.5 (07-Jan-2020)
ext2fs_open2: Chybné magické číslo v superbloku
fsck.ext4: Neplatný superblok, zkouším záložní bloky…
fsck.ext4: Chybné magické číslo v superbloku při pokusu otevřít /dev/sdb

Superblok nemohl být načten nebo nepopisuje správný systém souborů
ext2/ext3/ext4. Pokud je zařízení platné a opravdu obsahuje systém
souborů ext2/ext3/ext4 (a ne swap nebo UFS nebo něco jiného), pak je
superblok poškozen a můžete zkusit spustit e2fsck s jiným superblokem:
    e2fsck -b 8193 <zařízení>
nebo
    e2fsck -b 32768 <zařízení>

Nalezena tabulka rozdělení disku gpt v /dev/sdb

~$ sudo smartctl -x /dev/sdb
[sudo] heslo pro petr:                     
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.9.3-050903-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Samsung based SSDs
Device Model:     Samsung SSD 850 EVO 500GB
Serial Number:    S21JNXAGB29850D
LU WWN Device Id: 5 002538 d407c9484
Firmware Version: EMT02B6Q
User Capacity:    500 107 862 016 bytes [500 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2, ATA8-ACS T13/1699-D revision 4c
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Tue Nov  3 20:46:18 2020 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
AAM feature is:   Unavailable
APM feature is:   Unavailable
Rd look-ahead is: Enabled
Write cache is:   Enabled
DSN feature is:   Unavailable
ATA Security is:  Disabled, NOT FROZEN [SEC1]
Wt Cache Reorder: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00)	Offline data collection activity
					was never started.
					Auto Offline Data Collection: Disabled.
Self-test execution status:      (   0)	The previous self-test routine completed
					without error or no self-test has ever 
					been run.
Total time to complete Offline 
data collection: 		(    0) seconds.
Offline data collection
capabilities: 			 (0x53) SMART execute Offline immediate.
					Auto Offline data collection on/off support.
					Suspend Offline collection upon new
					command.
					No Offline surface scan supported.
					Self-test supported.
					No Conveyance Self-test supported.
					Selective Self-test supported.
SMART capabilities:            (0x0003)	Saves SMART data before entering
					power-saving mode.
					Supports SMART auto save timer.
Error logging capability:        (0x01)	Error logging supported.
					General Purpose Logging supported.
Short self-test routine 
recommended polling time: 	 (   2) minutes.
Extended self-test routine
recommended polling time: 	 ( 265) minutes.
SCT capabilities: 	       (0x003d)	SCT Status supported.
					SCT Error Recovery Control supported.
					SCT Feature Control supported.
					SCT Data Table supported.

SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAGS    VALUE WORST THRESH FAIL RAW_VALUE
  5 Reallocated_Sector_Ct   PO--CK   100   100   010    -    0
  9 Power_On_Hours          -O--CK   096   096   000    -    16243
 12 Power_Cycle_Count       -O--CK   094   094   000    -    5252
177 Wear_Leveling_Count     PO--C-   096   096   000    -    75
179 Used_Rsvd_Blk_Cnt_Tot   PO--C-   100   100   010    -    0
181 Program_Fail_Cnt_Total  -O--CK   100   100   010    -    0
182 Erase_Fail_Count_Total  -O--CK   100   100   010    -    0
183 Runtime_Bad_Block       PO--C-   100   099   010    -    0
187 Uncorrectable_Error_Cnt -O--CK   100   100   000    -    0
190 Airflow_Temperature_Cel -O--CK   073   051   000    -    27
195 ECC_Error_Rate          -O-RC-   200   200   000    -    0
199 CRC_Error_Count         -OSRCK   099   099   000    -    53
235 POR_Recovery_Count      -O--C-   099   099   000    -    465
241 Total_LBAs_Written      -O--CK   099   099   000    -    47236120647
                            ||||||_ K auto-keep
                            |||||__ C event count
                            ||||___ R error rate
                            |||____ S speed/performance
                            ||_____ O updated online
                            |______ P prefailure warning

General Purpose Log Directory Version 1
SMART           Log Directory Version 1 [multi-sector log support]
Address    Access  R/W   Size  Description
0x00       GPL,SL  R/O      1  Log Directory
0x01           SL  R/O      1  Summary SMART error log
0x02           SL  R/O      1  Comprehensive SMART error log
0x03       GPL     R/O      1  Ext. Comprehensive SMART error log
0x06           SL  R/O      1  SMART self-test log
0x07       GPL     R/O      1  Extended self-test log
0x09           SL  R/W      1  Selective self-test log
0x10       GPL     R/O      1  NCQ Command Error log
0x11       GPL     R/O      1  SATA Phy Event Counters log
0x13       GPL     R/O      1  SATA NCQ Send and Receive log
0x30       GPL,SL  R/O      9  IDENTIFY DEVICE data log
0x80-0x9f  GPL,SL  R/W     16  Host vendor specific log
0xa1           SL  VS      16  Device vendor specific log
0xa5           SL  VS      16  Device vendor specific log
0xce           SL  VS      16  Device vendor specific log
0xe0       GPL,SL  R/W      1  SCT Command/Status
0xe1       GPL,SL  R/W      1  SCT Data Transfer

SMART Extended Comprehensive Error Log Version: 1 (1 sectors)
No Errors Logged

SMART Extended Self-test Log Version: 1 (1 sectors)
No self-tests have been logged.  [To run self-tests, use: smartctl -t]

Warning! SMART Selective Self-Test Log Structure error: invalid SMART checksum.
SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
  255        0    65535  Read_scanning was never started
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

SCT Status Version:                  3
SCT Version (vendor specific):       256 (0x0100)
Device State:                        SCT command executing in background (5)
Current Temperature:                    27 Celsius
Power Cycle Min/Max Temperature:     27/40 Celsius
Lifetime    Min/Max Temperature:      0/70 Celsius
Under/Over Temperature Limit Count:  4294967295/4294901760
SMART Status:                        0xffff (Reserved)

SCT Temperature History Version:     2
Temperature Sampling Period:         1 minute
Temperature Logging Interval:        10 minutes
Min/Max recommended Temperature:      0/70 Celsius
Min/Max Temperature Limit:            0/70 Celsius
Temperature History Size (Index):    128 (2)

Index    Estimated Time   Temperature Celsius
   3    2020-11-02 23:30     ?  -
 ...    ..(123 skipped).    ..  -
 127    2020-11-03 20:10     ?  -
   0    2020-11-03 20:20    40  *********************
   1    2020-11-03 20:30    27  ********
   2    2020-11-03 20:40    27  ********

SCT Error Recovery Control:
           Read: Disabled
          Write: Disabled

Device Statistics (GP/SMART Log 0x04) not supported

Pending Defects log (GP Log 0x0c) not supported

SATA Phy Event Counters (GP Log 0x11)
ID      Size     Value  Description
0x0001  2           11  Command failed due to ICRC error
0x0002  2            8  R_ERR response for data FIS
0x0003  2            8  R_ERR response for device-to-host data FIS
0x0004  2            0  R_ERR response for host-to-device data FIS
0x0005  2            0  R_ERR response for non-data FIS
0x0006  2            0  R_ERR response for device-to-host non-data FIS
0x0007  2            0  R_ERR response for host-to-device non-data FIS
0x0008  2            0  Device-to-host non-data FIS retries
0x0009  2           14  Transition from drive PhyRdy to drive PhyNRdy
0x000a  2           14  Device-to-host register FISes sent due to a COMRESET
0x000b  2            0  CRC errors within host-to-device FIS
0x000d  2            0  Non-CRC errors within host-to-device FIS
0x000f  2            0  R_ERR response for host-to-device data FIS, CRC
0x0010  2            0  R_ERR response for host-to-device data FIS, non-CRC
0x0012  2            0  R_ERR response for host-to-device non-data FIS, CRC
0x0013  2            0  R_ERR response for host-to-device non-data FIS, non-CRC

---

---

Odpovědi

[Pavel 'TIGER' Růžička]

Nedávno jsem měl podobný problém, SSD jsem dal do jiného zařízení a ejhle, nic mu nebylo. Tak jsem jej naformátoval, vrazil zpět do původního zařízení a už tam zase dva měsíce jede. Ale pokud by ukazoval chyby i v jiném zařízení, tak bych jej raději odepsal a dal nový. Při těch cenách nemá smysl s tím cokoliv jiného vymýšlet.

[ewew]

Keď sa disk pripaja a odpaja počas chodu. To znamená, že je tam nejaký problém, ktorý sa firmvér pokúša vyriešiť. Pomohol by nejaký výpis čo sa počas udalosti dialo.

e2fsck si spustil na celom disku. Lepšie je to spúštať na particii.

[Petr Fiedler]

Vypadá to nadějně. Zkusím ještě jednou obnovit OS Clonezillou.

~$ sudo fsck.ext4 /dev/sdb1
e2fsck 1.44.1 (24-Mar-2018)
evo: čistý, 11/30531584 souborů, 2196279/122096384 bloků

~$ sudo fsck.ext4 /dev/sdb
e2fsck 1.44.1 (24-Mar-2018)
ext2fs_open2: Chybné magické číslo v superbloku
fsck.ext4: Neplatný superblok, zkouším záložní bloky…
fsck.ext4: Chybné magické číslo v superbloku při pokusu otevřít /dev/sdb

Superblok nemohl být načten nebo nepopisuje správný systém souborů
ext2/ext3/ext4. Pokud je zařízení platné a opravdu obsahuje systém
souborů ext2/ext3/ext4 (a ne swap nebo UFS nebo něco jiného), pak je
superblok poškozen a můžete zkusit spustit e2fsck s jiným superblokem:
    e2fsck -b 8193 <zařízení>
nebo
    e2fsck -b 32768 <zařízení>

Nalezena tabulka rozdělení disku gpt v /dev/sdb

[k3dAR]

jak psal ewew "lepsi na partici", tak ono je to nutne na "partici" protoze pokud mas disk rozdelenej (coz mas) a neformatoval si primo celej disk sdb (coz neformatoval), tak proste filesystem na sdb neni...

kdyz se odpojuje/pripojuje, zkoukni zda/co zobrazi dmesg... pripadne zkus rovnou vymenit sata kabel a pouzit jinou vetev nebo aspon konektor pro sata napajeni, tedy v pripade ze jde o PC, pokud jde o NB, zkus to SSD v jinem a/nebo v USB prevodniku...

[Petr Fiedler]

Hele, a když máš disk např. jen na data, tak je lepší mít naformátovaný rovnou celý disk, nebo je lepší na něm vytvořit oddíl? Bavíme se o ext4.

[MMi]

Taky se mrkni na smartctl statusy...

[lertimir]

je to v zásade jedno. Celým diskem získáš cca 1MB prostoru což při současných velikostech je nezajímavé. Ztratíš tím možnost zmenšit původní a vytvořit si nový oddíl, ale to také je k ničemu, když nemáš nějaké virtualizované prostředí.

[jiwopene]

U ext4 je to ± jedno. Pokud je na oddílu, můžete ho případně zmenšit (prvně FS pomocí resize2fs, pak oddíl) a zbylý prostor použít pro jiný oddíl.

Teoreticky by použití oddílu mělo trochu zpomalit přístupy, ale ten rozdíl by měl být u klasického HDD téměř neměřitelný. Pokud se nepletu, tak Linuxová implementace je taková, že není rozdíl žádný.

Pokud se rozhodnete použít dělení disku, pečlivě si zkontrolujte to, kde přesně oddíl vytváříte. Oddél by měl být zarovnaný jak na fyzické bloky disku, tak i bloky filesystému. Pokud není, bude se přenášet více dat. Příklad: Mám disk i filesystém s velikostí bloku 2048 B. Oddíl začíná na bajtu 2048n + 1024. Pro přečtení bloku filesystém musí číst vždy dva bloky, protože nejsou zarovnané.

Pokud použijete LVM nebo ZFS, většinou nemá smysl disk dělit, protože LVM (resp. ZFS) umí vytvořit blokvé zařízení v rámci svého oddílu. Zde mohou být asi jen dva důvody dělení: pro údržbu (část disku se nechá volná jako místo navíc) a kvůli kompatibilitě (zavaděč, BIOS, jiný OS, …).

[Petr Fiedler]

Ten příklad vůbec nechápu.

Brzy si budu pořizovat novou sestavu a čeká mě instalace. Ještě nevím, jestli zvolím LUKS + LVM + ext4, nebo LUKS + Btrfs, každopádně použiju jednu z těchto dvou variant:

LUKS + LVM + ext4:

sda            ~ 466 GiB
volné místo        1 MiB
sda1 bios_grub     1 MiB
sda2 EFI           1 GiB
sda3             zbytek volného místa
  luks
    lvm-rootfs   380 GiB
    lvm-swap      40 GiB
    volné místo  zbytek volného místa (na lvm snapshot)

LUKS + Btrfs:

sda            ~ 466 GiB
volné místo        1 MiB
sda1 bios_grub     1 MiB
sda2 EFI           1 GiB
sda3             zbytek volného místa
  luks
    @home        zbytek volného místa
    @swap         40 GiB

Něco jsem si teď o tom přečetl a fyzické bloky u většiny disků by měly být velké 4 KiB. Souborový systém by měl mít bloky velké 512 B. Takže obě ty varianty by měly být v pořádku, ne?

Ještě jsem našel tohle, ale nedovedu posoudit, jestli je to pravda. Co myslíš?

Díval jsem se do man parted a je tam parametr --align s více volbami, takže v terminálu se to dá zarovnat, když člověk ví co dělá. Instalátor a GParted to mají předpokládám pořešeno. I když si teď vybavuji, že instalátor Debianu (já používám Mint) na mě křičel, že nemám zarovnaný EFI oddíl. Tak teď nevím,jestli to bylo plus, nebo mínus.

[jiwopene]

U EFI oddílu to moc nevadí, protože ten se použije většínou jen při bootování a aktualizacích.

Problémy se zarovnáním (stav, ve kterém blok souborového systému nezačíná na začátku fyzického bloku) způsobí více přístupů k disku než je nutné. V závislosti na použití disku se to může projevit více či méně, ale je lepší se tomu vyhnout.

Parted by měl s --align=optimal vhodně zarovnat oddíly sám.

[Petr Fiedler]

Dík.

[Petr Fiedler]

Tak tentokrát jsem mezi SSD a HDD prohodil jen napájecí kabely a UEFI SSD opět nevidělo. Tím se zúžil výběr na datový kabel, switch, nebo port na MB. Takže jsem začal datovým kabelem a zatím vše funguje. Tak uvidíme.

[Peter Golis]

Vidím tam nejaké CRC chyby. Je kábel v poriadku, a konektory sú dobre spojené, niesú zoxidované že by tam boli poruchy prenosu?

Mohol by si, ak už na tom disku nemáš dáta, to SSD na kompletku prehnať cez blkdiscard že by si FW v tichosti premapovalo vypoužívané pam. bunky?

Dalo by sa skontrolovať pre budúcnosť ako máš definovaný fstrim, a na akom FS? Ten fstrim zvykne byť spúšťaný raz táždenne cez cron alebo fstrim.timer , ale niektorí ľudia si to vypínajú z historických dôvodov. Kedysi to bolo dokonca ako parameter pri mounte pre EXTFS, alebo na to sú náhradné príkazy zpool trim pre ZFS. Pri iných FS som to nesledoval, ale napríklad XFS používa premenlivú veľkosť bloku, a neviem či je kvôli TRIMu vhodný ak SSD používajú pevnú veľkosť bloku.

[Petr Fiedler]

Díky za odpověď Peter.

Vidím tam nejaké CRC chyby.

No to je přesně to, proč jsem sem napsal. Já tomu výpisu vůbec nerozumím a o CRC chybách slyším prvně.

Je kábel v poriadku, a konektory sú dobre spojené, niesú zoxidované že by tam boli poruchy prenosu?

Nedávno jsem zjistil, že mám SSD zapojeno do špatného SATA konektoru na MB. Tak jsem je zapojil do správného konektoru a vyměnil datový kabel za nový. Všechny konektory na MB jsem pořádně dotlačil, takže mi i začalo fungovat front USB o kterém jsem si už ~ 2 roky myslel, že je po něm. Všechna SATA zařízení mám zapojena do SATA switcheru, abych si je mohl dle libosti zapínat/vypínat. Takže možností k prozkoumání je více. Že by to mohlo být kabelem/switcherem/portem mě včera taky napadlo, ale chtěl jsem se zde napřed zeptat, protože v mých podmínkách se s pc špatně manipuluje. Dnes to vše zkusím.

Mohol by si, ak už na tom disku nemáš dáta, to SSD na kompletku prehnať cez blkdiscard že by si FW v tichosti premapovalo vypoužívané pam. bunky?

Mohl. Neškodí to ale tomu SSD? Jestli to chápu správně, tak se zapíše půl TB, ne?

Dalo by sa skontrolovať pre budúcnosť ako máš definovaný fstrim, a na akom FS?

Díval jsem se teď do /etc/cron.* , ale fstrim tam nevidím. Píšu teď ale z Mint 19.3 a včera mi vytuhnul Mint 20. Možná je to v něm jinak. Každopádně ohledně fstrim jsem nic neměnil a používám výchozí nastavení distra. FS = ext4.

~$ systemctl -a
fstrim.service    loaded    inactive dead    Discard unused blocks

Odpoledne|večer napíšu, jak jsem dopadl.

[Peter Golis]

Já tomu výpisu vůbec nerozumím a o CRC chybách slyším prvně.

Dosť často sa jedná o chyby pri prenose údajov. CRC je predsa Cyclic Redundancy Check, a overuje že dátový balíček je konzistentný a napríklad prešiel bez poškodenia z disku cez kabeláž do radiča diskov. Ale nehovorí o tom, či bol blok údajov korektne prečítaný alebo zapísaný, na to sú iné technológie.

Dnes to vše zkusím.

Prajem veľa trpezlivosti, mechanickej zručnosti a málo škrkancov na rukách.

Neškodí to ale tomu SSD? Jestli to chápu správně, tak se zapíše půl TB, ne?

TRIM nezapisuje. TRIM označuje bloky na uvoľnenie, aby elektronika vykonala Wear Leveling. Občas to má aj efekt že elektronika vyhodí poškodené bunky, a nahradí ich rezervnými. Tú náhradu vadných blokov by mala elektronika disku zapísať aj do SMART, ale zdržím sa komentárov.

Díval jsem se teď do /etc/cron.* , ale fstrim tam nevidím.

Ak máš systemd distribúciu, tak ten trim zvykne byť od výroby nastavený na týždennú bázu. V tom timeri si môžeš všimnúť riadok OnCalendar kde to uvidíš.

Inak, ľudia to vypínali nie kvôli životnosti disku, ale aby ten TRIM a Wear Leveling nespomaľoval stroje v nevhodných časoch. Asi by si nebol rád keby sa ti spomalil disk na ktorom beží databáza v ktorej akurát púšťaš uzávierku ktorá musí byť do rána hotová, a zmeškáš termín. Alebo keby sa ti na virtuálnej farme naraz spustil TRIM z desiatok alebo stoviek virtuálnych počítačov.

Ja si napríklad ten TRIM doma púšťam aj podľa potreby, to SSD mám len na testovacie VM. V januári som si ublogol o výkonostnom prepade ktorý sa prejavil pri tej mojej lacnej hračke (SSD) ktorej výkon po zaplnení SLC padol na cca 1/5 deklarovaného výkonu. Po TRIMe sa vrátil výkon do starých koľají.

[Petr Fiedler]

Díky za vysvětlení.

[Aleš Kapica]

Ty CRC chyby jsou typické pro vadné spojení. Může to být kabel, odcházející konektor na desce, i odcházející konektor na disku. Děsně blbě se odhaluje příčina. Obzvláště když už nemáš žádné volné porty na desce.

[Petr Fiedler]

Díky.

[Peter Golis]

Tiež mám ten dojem že to asi bude ten SATA prepínač, najmä ak je mechanický alebo nebol stavaný na také prenosové rýchlosti.

[Petr Fiedler]

Takže prozatím jsem udělal to, že jsem pouze přehodil kšandy z SSD na HDD a naopak. S ničím jiným jsem zatím nehýbal. Na tom HDD mám testovací Mint a tak jsem jej nahodil a čekal, kdy se HDD přestane točit. Jenže nepřestal. Tak jsem na to SSD pustil blkdiscard a pak jsem na ně nainstaloval Mint. Zajímalo mě, jestli to vůbec nabootuje. Nabootovalo. Takže jsem Clonezillou obnovil zálohu svého Mintu a zatím vše šlape. Počítač mám tedy ještě stále na stole bez bočnic a ty kšandy jsou stále opačně. Zítra|pozítří si pustím ten testovací Mint a budu sledovat, jak se to bude chovat. Pokud bude vše OK, tak zase vrátím kšandy nazpět a hotovo.

Jinak ten SATA switcher mám tento.

[Pavel 'TIGER' Růžička]

Tam stačí vadnej kondík a může to dělat neplechu.

[lertimir]

Stejně tak stačí prach v konektoru. A stalo se mi že tam po čase prach "zalezl" a kabel začal zlobit (chyby přenosu, odpojování disku, a bohužel i chyby ve smart logu, kterých se nedá zbavit). Po vyfoukání konektorů (kompresorem ne sprayem) a isopropylalkohol na vyčištění vše jede další dva roky.

[Petr Fiedler]

Možná mě to taky čeká. Známý má v práci kompresor na ofoukávání pilin z pracovního oděvu, takže to by nebyl problém. Ale jak přesně ty konektory tím isopropylalkoholem čistíš? Vatovými tyčinkami?

[Petr Fiedler]

Takže jsem kšandy přehodil zpátky, pc vyčistil, dotlačil všechny konektory a vše je zatím OK.

[Peter Golis]

Tak teda držíme palce nech to funguje aj naďalej.

[Petr Fiedler]

Doufám, díky.

[Petr Fiedler]

BTW: po blkdiscard se mi zvedl wear_leveling_count ze 75 na 76. Ale i těch 75 po 5 letech provozu není špatné, ne?

[Petr Fiedler]

Tak systém mi vytuhnul úplně stejně jako před tím a zase jsem jej musel vypnout natvrdo. Před pár dny (před tím prvním vytuhnutím) jsem si nainstaloval Ubuntu Mainline Kernel Installer a začal jsem používat nejnovější jádra, takže je to možná tím. Ted jsem zavedl stabilní distribuční jádro 5.4.0-52, tak uvidíme.

[Petr Fiedler]

Tak jádrem to není. Probudil jsem pc ze spánku a ani se nezobrazilo pole pro zadání hesla. Zůstalo to viset na spořiči. Po tvrdém vypnutí a zapnutí UEFI to SSD ani nezobrazuje v boot menu. Když k tomu přičtu, že při tom vytuhnutí jsem po zadání jakéhokoli příkazu v terminálu dostal zpět "Chyba vstupu/výstupu", tak to musí být buď tím SATA switchem, napájecím a nebo datovým kabelem. Takže zítra repete.

[Pavel 'TIGER' Růžička]

Opomenul si zmínit zdroj, od toho bych to začal měřit.

[Petr Fiedler]

Zdroj nepředpokládám jako příčinu. V pc mám 3 disky jeden SSD a dva HDD. Oba HDD fungují dobře a to mají IMHO větší odběr, než SSD, takže kdyby to bylo napájením, tak by na tom mělo být SSD nejlépe. Zlobí ale jako jediné, takže zdrojem to asi nebude.

V primární OS na tom SSD jsem dostával po zadání některých příkazů varování o chybějícím superbloku atd. Nevěděl jsem, jestli jsem to nezpůsobil tím vypnutím natvrdo. Tak jsem se rozhodl OS obnovit Clonezillou, ale narazil jsem na podivnou chybu. Clonezilla mi stále tvrdila, že sdb1 je zaneprázdněný a že nebude pokračovat. A bylo jedno, jestli sdb1 byla fleška, nebo disk se zálohou. Flešku jsem přeformátoval, ale nepomohlo to. Nepomohlo stáhnout Clonezillu znovu a nepomohlo ani stáhnout stable. Smazal jsem EFI + OS na SSD a vytvořil nový oddíl, ale taky to nepomohlo. Jestli to může souviset nevím. Každopádně zkusím jiný port na MB a switch pryč, neob jiný port.

[Pavel 'TIGER' Růžička]

Stačí špatný konektor na napájecí kšandě (nemusí být nutně vadný celý zdroj). U SATA konektoru se to neděje tak často, jako u MOLEXu, ale už jsem to také potkal.

[Petr Fiedler]

Já mám v pc SATA switch. Do něj jsou zapojena všechna bloková zařízení a z něj vede jediný kabel do zdroje. Pokud tedy 2 HDD fungují dobře a SSD ne, nemůže to být zdrojem. V tomto případě ne.

[Petr Fiedler]

Takže když to shrnu:

Na SSD jsem znovu vytvořil gpt, sda1 a pustil trim. Potom jsem sda1 smazal a úložiště rozdělil dle potřeby.

Vyměnil jsem datový kabel, ale to nepomohlo.

Vrátil jsem datový kabel do SATA portu, ve kterém byl roky a ze kterého jsem jej předělal vedle pár týdnu před tím, než se problémy objevily.

Pár dnů jsem testoval a vše běží jak má.

Čím to bylo nevím, protože ten SATA port, ve kterém to SSD zlobilo byl roky obsazen kabelem od HDD a problémy se neobjevovaly. Takže jsem tam ten HDD opět vrátil a budu to pozorovat.

Díky všem.