Filesystem che passa in sola lettura

0 views
Skip to first unread message

Giancarlo Martini

unread,
Oct 21, 2021, 1:50:02 PMOct 21
to
Salve lista, 
da qualche tempo, sul pc di casa, (Linux gianc-msi 5.14.0-2-amd64 #1 SMP Debian 5.14.9-2 (2021-10-03) x86_64 GNU/Linux)
senza nessun motivo apparente il sistema si blocca, 1 max 2 volte a settimana.

Passo sulla prima console (ctrl+alt+f1) e trovo scritto 
systemd-journald[xxx]: Failed to rotate /var/log/journal/xyxyxyxyxyyxyx/YXYXY: Read-only file system
systemd-journald[xxx]: Failed to write entry ....

ma com'è possibile che il file system passi nella modalità sola lettura da solo?

Ho guardato su internet e potrebbe essere il disco, ma, con un disco difettoso è possibile che gli unici problemi si abbiano con journal quando va ad aggiornare il log?

Grazie

--
Giancarlo Martini
(Replace 'AAA' con '@') 
mailto:giancarlomartiniAAAgmail.com


Pol Hallen

unread,
Oct 22, 2021, 2:10:03 PMOct 22
to
a me è capitato diverse volte in tempi diversi: una volta ho risolto con
un semplice fsck, un'altra meno fortunata è stato un alert ad un disco
prossimo alla morte 😅

prova a fare un test con smartctl

Pol
> mailto:giancarlomartiniAAAgmail.com <mailto:giancarlomartiniAAAgmail.com>
>
>

--
Pol

Davide Prina

unread,
Oct 22, 2021, 4:00:03 PMOct 22
to
On 21/10/21 19:32, Giancarlo Martini wrote:

> ma com'è possibile che il file system passi nella modalità sola lettura da
> solo?

perché glielo hai detto tu... o meglio nei file di configurazione è
impostato questo comportamento.

Se esegui questa istruzione dovresti avere un risultato simile a quello
sotto indicato
$ cat /etc/fstab | grep "/ "
UUID=xxxxx / ext4 errors=remount-ro 0 1

e qui è esplicitamente indicato che se incontra degli errori deve fare
il remount della partizione di root in sola lettura.

> Ho guardato su internet e potrebbe essere il disco, ma, con un disco
> difettoso è possibile che gli unici problemi si abbiano con journal quando
> va ad aggiornare il log?
potrebbe essere che c'è un settore danneggiato e tale settore è
attualmente usato in un file di log... o magari c'è un errore logico ed
è proprio su un file di log.

Come ti hanno suggerito è consigliabile eseguire prima un check del tuo
disco con fsck, per verificare se ci sono errori logici e correggerli e
poi un check con lo strumento adatto per il tuo disco per trovare errori
fisici.

Con i dischi tradizionali se ci sono dei settori danneggiati è possibile
marcarli come tali e se vedi che sono pochi e non proliferano, allora
potrebbe essere abbastanza sicuro usare il disco, altrimenti è
consigliato comprarne subito uno nuovo.

Se invece è un disco a stato solido penso che la cosa più saggia sia di
cambiarlo.

I backup sono comunque sempre d'obbligo in ogni caso.

Ciao
Davide
--
I didn't use Microsoft machines when I was in my operational phase,
because I couldn't trust them.
Not because I knew that there was a particular back door or anything
like that, but because I couldn't be sure.
Edward Snowden

Giancarlo Martini

unread,
Oct 24, 2021, 4:20:03 AMOct 24
to
Ciao Davide, 
in realtà nel mio fstab il mio parametro errors=remount-ro non c'è, sarà impostato di default, e questo spiega perchè mi ritrovo il filesystem in lettura.
Il disco, ssd, l'ho già controllato (con gli smart tools e fsck) e non ho trovato errori.
Ciao e grazie a tutti
--
Giancarlo Martini
(Replace 'AAA' con '@')  

gerlos

unread,
Oct 25, 2021, 6:40:03 AMOct 25
to
Il 25/10/21 09:17, Diego Zuccato ha scritto:
> Il 24/10/2021 10:16, Giancarlo Martini ha scritto:
>
> Ciao Giancarlo.
>
>> in realtà nel mio fstab il mio parametro errors=remount-ro non c'è,
>> sarà impostato di default, e questo spiega perchè mi ritrovo il
>> filesystem in lettura.
> Se guardi nei log (dmesg) probabilmente trovi qualche info in più
> sulla ragione per la quale è stato messo ro.
>
>> Il disco, ssd, l'ho già controllato (con gli smart tools e fsck) e
>> non ho trovato errori.
> Prova con badblocks (da una distro live). SMART, secondo la mia
> esperienza, non è più affidabile del lancio di una monetina: ho avuto
> dischi in PRE-FAIL per anni che non hanno mai dato problemi, altri che
> senza nessun avviso hanno deciso che era il loro momento... L'unica
> cosa utile è il monitoraggio della temperatura.
>

Concordo sull'uso di badblocks, in modalità di lettura/scrittura non
distruttiva.

Nota una cosa: dipende dall'hardware, ma durante il controllo con
badblocks il firmware stesso del disco potrebbe rilevare i blocchi
guasti, e riallocarli automaticamente altrove, quindi 5 blocchi
danneggiati trovati al primo "giro" di badblocks potrebbero diventare
"automagicamente" invisibili in eventuali controlli successivi.

Se si tratta di "pochi" blocchi la cosa dovrebbe essere senza ulteriori
conseguenze, e potresti continuare ad usare il disco come prima (magari
facendo un controllino di tanto in tanto, giusto per prudenza...).

saluti,

gerlos

Alessandro Rubini

unread,
Oct 25, 2021, 8:40:03 AMOct 25
to
> Concordo sull'uso di badblocks, in modalità di lettura/scrittura non
> distruttiva.

Davvero? Gli SSD sono brutte beste.

> il firmware stesso del disco potrebbe rilevare i blocchi
> guasti, e riallocarli automaticamente altrove,

Appunto. Il disco e` un computer, che fa quello che vuole (e quello che
puo`) con i blocchi di flash. Che, come sappiamo, e` fatta per scoppiare.

Sono contento di avere SSD sul portatile, per i problemi delle vibrazioni,
ma non metterei i miei dati importanti su SSD. Appena posso faccio
push verso dischi veri.

Ora, il firmware, questo sconosciuto, cosa sa del mio filesystem?
Nulla. Pero` vede quali blocchi vengono scritti e quali no. Se un
blocco viene scritto, lo considera in uso. E` suo dovere preservarlo,
perche` una rilettura successiva deve ritornare lo stesso contenuto.

Un disco nuovo di fabbrica parte vuoto (dal punto di vista del
processore del disco, del "firmware"), un disco che ha passato un
badblocks r/w e` pieno al 100%. Il lavoro del micro diventa piu`
pesante, le prestazioni peggiorano e le scritture (= consumo di flash)
aumentano per preservare tutti quei blocchi di cui in realta` non ci
interessa.

Dove sbaglio? Esiste un trim globale per ripulire un disco dopo
badblocks? (https://en.wikipedia.org/wiki/Trim_(computing)) Se si, mi
aspetto che anche questo debba girare a bocce ferme, conoscendo la
struttura del filesystem in uso.

In ogni caso, la mappatura dei blocchi del "disco" su quelli della
flash e` aleatoria, fatico a capire come badblocks possa aiutare.

> quindi 5 blocchi danneggiati trovati al primo "giro" di badblocks
> potrebbero diventare "automagicamente" invisibili in eventuali
> controlli successivi.

Appunto. E` compito dell'altro microprocessore far vedere tutto a
posto. Se nemmeno lui ci riesce, e quando scrivo mi fa rileggere dati
differenti, il disco e` da buttare. Lo controllassimo noi, con un
UBIFS, non sarebbe da buttare, ma per noi e` una scatola nera, e se
inizia a comportarsi male non possiamo piu` fidarci.

Qualcuno piu` competente mi dica dove sbaglio: io ormai faccio solo
pcb, il resto e` troppo complesso.

/alessandro

Mauro

unread,
Oct 25, 2021, 8:50:03 AMOct 25
to

Il 25/10/21 14:30, Alessandro Rubini ha scritto:
> Sono contento di avere SSD sul portatile, per i problemi delle vibrazioni,
> ma non metterei i miei dati importanti su SSD. Appena posso faccio
> push verso dischi veri.


vabbe', dai... non demonizziamo gli ssd. e' vero che quando si rompono
addio a tutto il contenuto ma ormai tutti i provider dai grandi ai
piccini offrono i servizi su ssd... proprio cosi' malvagi non sono.

Giancarlo Martini

unread,
Oct 25, 2021, 9:00:03 AMOct 25
to
Badblocks, ottima idea, non ci avevo pensato. L'ho già usato per le se. Grazie


Il lun 25 ott 2021, 09:17 Diego Zuccato <diego....@unibo.it> ha scritto:
Il 24/10/2021 10:16, Giancarlo Martini ha scritto:

Ciao Giancarlo.

> in realtà nel mio fstab il mio parametro errors=remount-ro non c'è, sarà
> impostato di default, e questo spiega perchè mi ritrovo il filesystem in
> lettura.
Se guardi nei log (dmesg) probabilmente trovi qualche info in più sulla
ragione per la quale è stato messo ro.

> Il disco, ssd, l'ho già controllato (con gli smart tools e fsck) e non
> ho trovato errori.
Prova con badblocks (da una distro live). SMART, secondo la mia
esperienza, non è più affidabile del lancio di una monetina: ho avuto
dischi in PRE-FAIL per anni che non hanno mai dato problemi, altri che
senza nessun avviso hanno deciso che era il loro momento... L'unica cosa
utile è il monitoraggio della temperatura.

--
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786

Marco Ciampa

unread,
Oct 25, 2021, 9:40:03 AMOct 25
to
On Mon, Oct 25, 2021 at 12:30:51PM +0200, gerlos wrote:
> Concordo sull'uso di badblocks, in modalità di lettura/scrittura non
> distruttiva.

Questa me la devi spiegare: come fa una scrittura a non essere
potenzialmente distruttiva?

Badblocks è un tool nato per i dischi rotanti, non ssd. Io eviterei di
usarlo per gli SSD. Una "passata" di questo e il disco perde un bel po'
della sua vita potenziale... ed inoltre è inutile:

https://kupczynski.info/2018/11/02/ssd-failure.html


--

Saluton,
Marco Ciampa
Reply all
Reply to author
Forward
0 new messages