From michele.mordenti@gmail.com Mon Aug 12 09:10:08 2024 From: michele.mordenti@gmail.com (Michele Mordenti) Date: Mon, 12 Aug 2024 09:10:08 +0200 Subject: [FoLUG] =?utf-8?q?Il_solito_luned=C3=AC_mattina_al_lavoro?= Message-ID: Questa mattina appena arrivato al lavoro decido di fare un bel backup dei dati sul mio portatile verso un bel PC con dischi meccanici, uso ancora il buon vecchio rsync. A fine procedura mi segnala che non è stato in grado di sincronizzare alcuni dati e scopro che ho una cartella (in questo esempio la generica /myDir) con questo comportamento: ls /myDir ls: lettura della directory '/myDir': Errore di input/output Il dmesg mi segnala questo: nvme0n1: I/O Cmd(0x2) @ LBA 454685016, 8 blocks, I/O Error (sct 0x2 / sc 0x81) critical medium error, dev nvme0n1, sector 454685016 op 0x0:(READ) flags 0x3000 phys_seg 1 prio class 0 EXT4-fs warning (device dm-0): htree_dirblock_to_tree:1082: inode #14180131: lblock 0: comm ls: error -5 reading directory block La situa: disco NVME con luksFS + EXT4 I dati della cartella incriminata sono del 2016 presenti nel backup, per fortuna non ho perso nulla (al momento) Idee per uscirne fuori? Ora farei un bel boot da live e fsck del disco, ma la domanda è: quanto mi devo preoccupare per la salute del disco e l'integrità dei miei dati? E' un incidente di percorso o meglio farsi assalire dalla paranoia? Buon monday morning :-( -- Michele Mordenti From ivan.fabris@gmail.com Mon Aug 12 10:14:24 2024 From: ivan.fabris@gmail.com (Ivan Fabris) Date: Mon, 12 Aug 2024 10:14:24 +0200 Subject: [FoLUG] =?utf-8?q?Il_solito_luned=C3=AC_mattina_al_lavoro?= In-Reply-To: References: Message-ID: Il giorno lun 12 ago 2024 alle ore 09:10 Michele Mordenti via FoLUG < folug@lists.linux.it> ha scritto: > > nvme0n1: I/O Cmd(0x2) @ LBA 454685016, 8 blocks, I/O Error (sct 0x2 / sc > 0x81) > critical medium error, dev nvme0n1, sector 454685016 op 0x0:(READ) flags > 0x3000 phys_seg 1 prio class 0 > > Paranoia va bene Fai un dd if=/dev/nvme0 of=/dev/null bs=4096 e vedi che ti dice. Con i dischi non meccanici non e' del tutto attendibile, ma non fa male From michele.mordenti@gmail.com Mon Aug 12 12:01:49 2024 From: michele.mordenti@gmail.com (Michele Mordenti) Date: Mon, 12 Aug 2024 12:01:49 +0200 Subject: [FoLUG] =?utf-8?q?Il_solito_luned=C3=AC_mattina_al_lavoro?= In-Reply-To: References: Message-ID: Sono partito da una live e montato il volume lucksfs nvme0n1p3 per poi eseguire un fsck.ext4 -f /dev/mapper/KUBUNTU Mi sono stati segnalati errori alcuni proprio nella cartella incriminata ed ho premuto come un picchio il tasto Y, fsck si è rifiutato di usare l'opzione "-a" ma tanto che ci vuoi fare, mi metterò mica a ricostruire a mano i settori del disco! A fine riparazione il kernel mi ha segnalato i soliti errori di accesso al disco [lun ago 12 09:09:10 2024] nvme0n1: I/O Cmd(0x2) @ LBA 454684792, 256 blocks, I/O Error (sct 0x2 / sc 0x81) [lun ago 12 09:09:10 2024] critical medium error, dev nvme0n1, sector 454684792 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0 [lun ago 12 09:09:28 2024] nvme0n1: I/O Cmd(0x2) @ LBA 454685016, 8 blocks, I/O Error (sct 0x2 / sc 0x81) [lun ago 12 09:09:28 2024] critical medium error, dev nvme0n1, sector 454685016 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 [lun ago 12 09:09:28 2024] Buffer I/O error on dev dm-0, logical block 56633643, async page read [lun ago 12 09:09:28 2024] nvme0n1: I/O Cmd(0x2) @ LBA 454685016, 8 blocks, I/O Error (sct 0x2 / sc 0x81) [lun ago 12 09:09:28 2024] critical medium error, dev nvme0n1, sector 454685016 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 [lun ago 12 09:09:28 2024] Buffer I/O error on dev dm-0, logical block 56633643, async page read Ho smontato il volume e letto l'intero disco come suggerito da Ivan: root@kubuntu:~# dd if=/dev/nvme0n1 of=/dev/null status=progress bs=4096 510376972288 bytes (510 GB, 475 GiB) copied, 448 s, 1,1 GB/s 125026902+0 records in 125026902+0 records out 512110190592 bytes (512 GB, 477 GiB) copied, 450,925 s, 1,1 GB/s Niente anomalie, dmesg non si è lamentato e nessuno si è fatto male. Per sicurezza ho nuovamente montato il disco e lanciato un nuovo fsck: niente anomalie, dmesg non si è lamentato e nessuno si è fatto male. Riavviato il portatile la cartella incriminata era nuovamente accessibile e conteneva i 24 files, file presenti anche nella /lost+found root@mm:~# ls -l /lost+found/ totale 15736 -rw-rw-r-- 1 micmord micmord 94697 nov 30 2016 '#14181398' -rw-rw-r-- 1 micmord micmord 1444262 nov 30 2016 '#14181399' -rw-rw-r-- 1 micmord micmord 62969 nov 30 2016 '#14181400' -rw-rw-r-- 1 micmord micmord 954590 nov 30 2016 '#14181401' -rw-rw-r-- 1 micmord micmord 121865 nov 30 2016 '#14181402' -rw-rw-r-- 1 micmord micmord 1855237 nov 30 2016 '#14181403' -rw-rw-r-- 1 micmord micmord 73265 nov 30 2016 '#14181404' -rw-rw-r-- 1 micmord micmord 1112016 nov 30 2016 '#14181405' -rw-rw-r-- 1 micmord micmord 21868 nov 30 2016 '#14181406' -rw-rw-r-- 1 micmord micmord 324667 nov 30 2016 '#14181407' -rw-rw-r-- 1 micmord micmord 144905 nov 30 2016 '#14181408' -rw-rw-r-- 1 micmord micmord 2208055 nov 30 2016 '#14181409' -rw-rw-r-- 1 micmord micmord 71177 nov 30 2016 '#14181410' -rw-rw-r-- 1 micmord micmord 1079912 nov 30 2016 '#14181411' -rw-rw-r-- 1 micmord micmord 177113 nov 30 2016 '#14181412' -rw-rw-r-- 1 micmord micmord 2701454 nov 30 2016 '#14181413' -rw-rw-r-- 1 micmord micmord 78017 nov 30 2016 '#14181414' -rw-rw-r-- 1 micmord micmord 1187763 nov 30 2016 '#14181415' -rw-rw-r-- 1 micmord micmord 25217 nov 30 2016 '#14181416' -rw-rw-r-- 1 micmord micmord 366809 nov 30 2016 '#14181417' -rw-rw-r-- 1 micmord micmord 61121 nov 30 2016 '#14181418' -rw-rw-r-- 1 micmord micmord 926213 nov 30 2016 '#14181419' -rw-rw-r-- 1 micmord micmord 59633 dic 1 2016 '#14181420' -rw-rw-r-- 1 micmord micmord 905772 dic 1 2016 '#14181421' Ovviamente ho ripristinato i 24 files dal backup perché sì erano presenti, ma non proprio uguali agli originali: [micmord@mm ~]$ rsync -av --delete --progress root@z50:[OMISSIS]/2016/ [OMISSIS]/2016/ receiving incremental file list 11/run-20161101T092952.fit 11/run-20161101T092952.gpx 11/run-20161103T224703.fit 11/run-20161103T224703.gpx 11/run-20161106T070924.fit 11/run-20161106T070924.gpx 11/run-20161110T141209.fit 11/run-20161110T141209.gpx 11/run-20161113T090019.fit 11/run-20161113T090019.gpx 11/run-20161113T093202.fit 11/run-20161113T093202.gpx 11/run-20161116T131135.fit 11/run-20161116T131135.gpx 11/run-20161119T070602.fit 11/run-20161119T070602.gpx 11/run-20161122T201314.fit 11/run-20161122T201314.gpx 11/run-20161127T085913.fit 11/run-20161127T085913.gpx 11/run-20161127T093059.fit 11/run-20161127T093059.gpx 11/run-20161130T220508.fit 11/run-20161130T220508.gpx Boh, a questo punto direi incidente chiuso e aumenterò la frequenza dei backup. Altre idee? Dite sia buono procedere anche con la prova inversa? dd if=/dev/null of=/dev/nvme0n1 status=progress bs=4096 :-P Il giorno lun 12 ago 2024 alle ore 10:15 Ivan Fabris via FoLUG < folug@lists.linux.it> ha scritto: > Il giorno lun 12 ago 2024 alle ore 09:10 Michele Mordenti via FoLUG < > folug@lists.linux.it> ha scritto: > > > > > nvme0n1: I/O Cmd(0x2) @ LBA 454685016, 8 blocks, I/O Error (sct 0x2 / sc > > 0x81) > > critical medium error, dev nvme0n1, sector 454685016 op 0x0:(READ) flags > > 0x3000 phys_seg 1 prio class 0 > > > > > Paranoia va bene > Fai un dd if=/dev/nvme0 of=/dev/null bs=4096 e vedi che ti dice. > Con i dischi non meccanici non e' del tutto attendibile, ma non fa male > _______________________________________________ > FoLUG mailing list > FoLUG@lists.linux.it > https://lists.linux.it/listinfo/folug per cancellarsi dalla lista > > Canale Zulip Ufficiale. > Per iscriversi: > https://folug-imolug.zulipchat.com/join/r4kvfa2fzgop777im5xraijv/ > -- Michele Mordenti From michele.mordenti@gmail.com Mon Aug 12 12:24:23 2024 From: michele.mordenti@gmail.com (Michele Mordenti) Date: Mon, 12 Aug 2024 12:24:23 +0200 Subject: [FoLUG] =?utf-8?q?Il_solito_luned=C3=AC_mattina_al_lavoro?= In-Reply-To: References: Message-ID: Che poi per scrupolo mi sono fatto un diff tra i files ripristinati e quelli nella /lost+found e sono uguali. Unsafe Shutdowns: 13 Probabilmente ext4 è andato in banana una delle 13 volte che la batteria è morta durante il suspend2ram. Purtroppo ho un maledetto core i5 di 11° generazione che drena un'esagerazione di batteria anche in sospensione. Il giorno lun 12 ago 2024 alle ore 12:01 Michele Mordenti < michele.mordenti@gmail.com> ha scritto: > Sono partito da una live e montato il volume lucksfs nvme0n1p3 per poi > eseguire un fsck.ext4 -f /dev/mapper/KUBUNTU > > Mi sono stati segnalati errori alcuni proprio nella cartella incriminata > ed ho premuto come un picchio il tasto Y, fsck si è rifiutato di usare > l'opzione "-a" ma tanto che ci vuoi fare, mi metterò mica a ricostruire a > mano i settori del disco! > > A fine riparazione il kernel mi ha segnalato i soliti errori di accesso al > disco > [lun ago 12 09:09:10 2024] nvme0n1: I/O Cmd(0x2) @ LBA 454684792, 256 > blocks, I/O Error (sct 0x2 / sc 0x81) > [lun ago 12 09:09:10 2024] critical medium error, dev nvme0n1, sector > 454684792 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0 > [lun ago 12 09:09:28 2024] nvme0n1: I/O Cmd(0x2) @ LBA 454685016, 8 > blocks, I/O Error (sct 0x2 / sc 0x81) > [lun ago 12 09:09:28 2024] critical medium error, dev nvme0n1, sector > 454685016 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 > [lun ago 12 09:09:28 2024] Buffer I/O error on dev dm-0, logical block > 56633643, async page read > [lun ago 12 09:09:28 2024] nvme0n1: I/O Cmd(0x2) @ LBA 454685016, 8 > blocks, I/O Error (sct 0x2 / sc 0x81) > [lun ago 12 09:09:28 2024] critical medium error, dev nvme0n1, sector > 454685016 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 > [lun ago 12 09:09:28 2024] Buffer I/O error on dev dm-0, logical block > 56633643, async page read > > Ho smontato il volume e letto l'intero disco come suggerito da Ivan: > > root@kubuntu:~# dd if=/dev/nvme0n1 of=/dev/null status=progress bs=4096 > 510376972288 bytes (510 GB, 475 GiB) copied, 448 s, 1,1 GB/s > 125026902+0 records in > 125026902+0 records out > 512110190592 bytes (512 GB, 477 GiB) copied, 450,925 s, 1,1 GB/s > > Niente anomalie, dmesg non si è lamentato e nessuno si è fatto male. > > Per sicurezza ho nuovamente montato il disco e lanciato un nuovo fsck: > niente anomalie, dmesg non si è lamentato e nessuno si è fatto male. > > Riavviato il portatile la cartella incriminata era nuovamente accessibile > e conteneva i 24 files, file presenti anche nella /lost+found > > root@mm:~# ls -l /lost+found/ > totale 15736 > -rw-rw-r-- 1 micmord micmord 94697 nov 30 2016 '#14181398' > -rw-rw-r-- 1 micmord micmord 1444262 nov 30 2016 '#14181399' > -rw-rw-r-- 1 micmord micmord 62969 nov 30 2016 '#14181400' > -rw-rw-r-- 1 micmord micmord 954590 nov 30 2016 '#14181401' > -rw-rw-r-- 1 micmord micmord 121865 nov 30 2016 '#14181402' > -rw-rw-r-- 1 micmord micmord 1855237 nov 30 2016 '#14181403' > -rw-rw-r-- 1 micmord micmord 73265 nov 30 2016 '#14181404' > -rw-rw-r-- 1 micmord micmord 1112016 nov 30 2016 '#14181405' > -rw-rw-r-- 1 micmord micmord 21868 nov 30 2016 '#14181406' > -rw-rw-r-- 1 micmord micmord 324667 nov 30 2016 '#14181407' > -rw-rw-r-- 1 micmord micmord 144905 nov 30 2016 '#14181408' > -rw-rw-r-- 1 micmord micmord 2208055 nov 30 2016 '#14181409' > -rw-rw-r-- 1 micmord micmord 71177 nov 30 2016 '#14181410' > -rw-rw-r-- 1 micmord micmord 1079912 nov 30 2016 '#14181411' > -rw-rw-r-- 1 micmord micmord 177113 nov 30 2016 '#14181412' > -rw-rw-r-- 1 micmord micmord 2701454 nov 30 2016 '#14181413' > -rw-rw-r-- 1 micmord micmord 78017 nov 30 2016 '#14181414' > -rw-rw-r-- 1 micmord micmord 1187763 nov 30 2016 '#14181415' > -rw-rw-r-- 1 micmord micmord 25217 nov 30 2016 '#14181416' > -rw-rw-r-- 1 micmord micmord 366809 nov 30 2016 '#14181417' > -rw-rw-r-- 1 micmord micmord 61121 nov 30 2016 '#14181418' > -rw-rw-r-- 1 micmord micmord 926213 nov 30 2016 '#14181419' > -rw-rw-r-- 1 micmord micmord 59633 dic 1 2016 '#14181420' > -rw-rw-r-- 1 micmord micmord 905772 dic 1 2016 '#14181421' > > > Ovviamente ho ripristinato i 24 files dal backup perché sì erano presenti, > ma non proprio uguali agli originali: > > [micmord@mm ~]$ rsync -av --delete --progress root@z50:[OMISSIS]/2016/ > [OMISSIS]/2016/ > receiving incremental file list > 11/run-20161101T092952.fit > 11/run-20161101T092952.gpx > 11/run-20161103T224703.fit > 11/run-20161103T224703.gpx > 11/run-20161106T070924.fit > 11/run-20161106T070924.gpx > 11/run-20161110T141209.fit > 11/run-20161110T141209.gpx > 11/run-20161113T090019.fit > 11/run-20161113T090019.gpx > 11/run-20161113T093202.fit > 11/run-20161113T093202.gpx > 11/run-20161116T131135.fit > 11/run-20161116T131135.gpx > 11/run-20161119T070602.fit > 11/run-20161119T070602.gpx > 11/run-20161122T201314.fit > 11/run-20161122T201314.gpx > 11/run-20161127T085913.fit > 11/run-20161127T085913.gpx > 11/run-20161127T093059.fit > 11/run-20161127T093059.gpx > 11/run-20161130T220508.fit > 11/run-20161130T220508.gpx > > Boh, a questo punto direi incidente chiuso e aumenterò la frequenza dei > backup. > > Altre idee? > > Dite sia buono procedere anche con la prova inversa? > dd if=/dev/null of=/dev/nvme0n1 status=progress bs=4096 :-P > > > Il giorno lun 12 ago 2024 alle ore 10:15 Ivan Fabris via FoLUG < > folug@lists.linux.it> ha scritto: > >> Il giorno lun 12 ago 2024 alle ore 09:10 Michele Mordenti via FoLUG < >> folug@lists.linux.it> ha scritto: >> >> > >> > nvme0n1: I/O Cmd(0x2) @ LBA 454685016, 8 blocks, I/O Error (sct 0x2 / sc >> > 0x81) >> > critical medium error, dev nvme0n1, sector 454685016 op 0x0:(READ) flags >> > 0x3000 phys_seg 1 prio class 0 >> > >> > >> Paranoia va bene >> Fai un dd if=/dev/nvme0 of=/dev/null bs=4096 e vedi che ti dice. >> Con i dischi non meccanici non e' del tutto attendibile, ma non fa male >> _______________________________________________ >> FoLUG mailing list >> FoLUG@lists.linux.it >> https://lists.linux.it/listinfo/folug per cancellarsi dalla lista >> >> Canale Zulip Ufficiale. >> Per iscriversi: >> https://folug-imolug.zulipchat.com/join/r4kvfa2fzgop777im5xraijv/ >> > > > -- > Michele Mordenti > -- Michele Mordenti From ivan.fabris@gmail.com Mon Aug 12 13:04:02 2024 From: ivan.fabris@gmail.com (Ivan Fabris) Date: Mon, 12 Aug 2024 13:04:02 +0200 Subject: [FoLUG] =?utf-8?q?Il_solito_luned=C3=AC_mattina_al_lavoro?= In-Reply-To: References: Message-ID: > > > Dite sia buono procedere anche con la prova inversa? > dd if=/dev/null of=/dev/nvme0n1 status=progress bs=4096 :-P > Siccome /dev/null e' scrivibile, conviene che lo sostituisci con una cosa read-only, tipo /dev/urandom, per migliori risultati :-P