Errore in fase di boot con SSD Samsung 850 EVO e Fedora 23

Fedora Linux Hardware
#1

Ciao a tutti
Ho un problema con il mio SSD Samsung 850EVO in fase di boot.
ho installato un dual boot winzoz 7 e fedora 23.
per ottimizzare l’uso dell’ssd su fedora ho adottato un po di accorgimenti come ad esempio ho tolto il journaling, ho aggiunto noatime nel mio fstab e discard per abilitare il TRIM
In fase di boot con fedora ho un blocco di 4 secondi per un timeout dovuto alla funzione NCQ (https://it.wikipedia.org/wiki/NCQ).
Riporto dmeg

    2.129117] input: ETPS/2 Elantech Touchpad as /devices/platform/i8042/serio4/input/input12
    6.030378] ata1.00: qc timeout (cmd 0x2f)
    6.030388] ata1.00: failed to get NCQ Send/Recv Log Emask 0x5
    6.030391] ata1.00: ATA-9: Samsung SSD 850 EVO 250GB, EMT01B6Q, max UDMA/133
    6.030395] ata1.00: 488397168 sectors, multi 1: LBA48 NCQ (depth 31/32)
    6.030399] ata1.00: failed to get Identify Device Data, Emask 0x40
    6.030408] ata1.00: failed to set xfermode (err_mask=0x40)

googlando un po ho provato a disabilitare la funzione NCQ aggiungendo libata.force=noncq in /etc/defaul/grub alla linea GRUB_CMDLINE_LINUX e l’errore è effettivamente sparito ma ho notato un calo delle prestazioni dell’SSD non trascurabile a mio avviso.
ecco il benchamark prima e dopo

con libata.force.noncq

/dev/sda:
Timing cached reads: 2860 MB in 2.00 seconds = 1430.85 MB/sec
Timing buffered disk reads: 630 MB in 3.01 seconds = 209.43 MB/sec

senza libata.force.noncq

/dev/sda:
Timing cached reads: 2826 MB in 2.00 seconds = 1414.19 MB/sec
Timing buffered disk reads: 808 MB in 3.01 seconds = 268.71 MB/sec
[root@localhost giuseppe]# hdparm -tT /dev/sdb

come si può notare il Timing buffered disk reads è calato di 60 MB/sec.
Un po troppo per i miei gusti in quanto quella velocità cala per sempre durante l’uso per PC quindi ho lasciato perdere questo “palliativo”
qualcuno mi può dar una mano?

grazie in anticipo

ciao

#2

Non mi affiderei in toto a quei valori di hdparam per calcolare la velocità del disco. Prova a fare qualche verifica con gnome-disks.
Terrei quella opzione al boot e verificherei per la presenza di aggiornamenti del firmware.
noatime non dovrebbe essere più necessario per gli ssd moderni e sconsiglio vivamente di non disabilitare il journaling (stai utilizzando ext4 senza journaling quindi?). A mio avviso è più importante verificare se lo scheduler per il tuo disco sia noop o deadline (non cfq):

cat /sys/block/sdb/queue/scheduler
#3

[quote=frafra]Non mi affiderei in toto a quei valori di hdparam per calcolare la velocità del disco. Prova a fare qualche verifica con gnome-disks.
Terrei quella opzione al boot e verificherei per la presenza di aggiornamenti del firmware.
noatime non dovrebbe essere più necessario per gli ssd moderni e sconsiglio vivamente di non disabilitare il journaling (stai utilizzando ext4 senza journaling quindi?). A mio avviso è più importante verificare se lo scheduler per il tuo disco sia noop o deadline (non cfq):

cat /sys/block/sdb/queue/scheduler

si sto usando un ext4 senza journaling ma che comunque da sei mesi mai andato in crash o comunque mai un problema.
Lo scheduler l’avevo impostato su noop

[giuseppe@localhost ~]$ cat /sys/block/sdb/queue/scheduler [noop] deadline cfq

quindi secondo te noatime non serve più?
come imposteresti tu un SSD su linux?

#4

Premessa: gli SSD “moderni” sono molto diversi da quelli che si trovavano in giro 5~10 anni fa. Le rotture degli SSD moderni sono dovute principalmente a problemi di firmware[1] e ai circuiti di alimentazione[2].

Esempi:
[list=1]
]OCZ utilizzava i controller Sandforce fuori specifica per guadagnare un paio di punti percentuali di performance rispetto ai rivali con problemi a discapito dell’affidabilità dell’SSD; i Samsung 840 EVO hanno avuto seri problemi di firmware (peggiorati dal fatto che la serie EVO utilizza NAND TLC anziché MLC); potrebbero seguire altri esempi…/]
]La mancanza di corrente può comportare la perdita di dati o addirittura l’intera rottura dell’SSD (a me purtroppo è capitato)/]
[/list]

Consigli (acquisto in ambito consumer):
[list=1]
]Controllare la garanzia (ad esempio: SanDisk Extreme PRO 10 anni, Samsung serie PRO tra i 5 o i 10 anni, Intel 535 5 anni)/]
]NAND MLC: SLC è per l’enterprise e le TLC sono meno robuste a fronte di un costo leggermente inferiore (quindi niente serie EVO di Samsung) [maggiori info: [url=https://en.wikipedia.org/wiki/Multi-level_cell]Wikipedia - Multi-level cell]/]
]Power loss protection: consiglio vivamente, anche se si ha un UPS o batteria può capitare di essere costretti a spegnere fisicamente il pc (quindi niente serie BX di Crucial bensì serie MX ad esempio)/]
[/list]

Consigli (configurazione):
[list=1]
]Journaling: non impatta più in maniera sensibile sulla vita dell’SSD, quindi è preferibile lasciarlo attivo/]
]TRIM/discard: può provocare problemi con alcuni firmware, lentezza e problemi di sicurezza se il disco è cifrato; rende più efficiente il lavoro del garbage collector, ma non è obbligatorio utilizzarlo: l’importante è avere un ssd con un buono spazio di overprovisioning o lasciare dello spazio libero/non partizionato/]
]noatime: alcuni programmi specifici potrebbero avere problemi; relatime è l’opzione di default ed è un ottimo compromesso; lazytime è presente a partire dal kernel 4.0 ed è probabilmente la migliore soluzione/]
]Scheduler: cfq è sconsigliato, utilizzare noop o deadline; nei sistemi sia con dischi meccanici sia con SSD è importante fare si che gli hard disk continuino ad utilizzare cfq per ragioni di performance/]
]Spostare più roba possibile in ram: può aver senso a prescindere dal dispositivo di archiviazione che si utilizza (per le performance in primis), ma è bene tenere a mente delle limitazioni di questo sistema (perdita di dati); overlayfs potrebbe essere una tecnologia da sfruttare in questo caso/]
]File system COW (Copy-on-write: niente journaling, si scrive sempre sullo spazio non utilizzato): i filesystem classici sono ottimizzati per gli hard disk; uso btrfs da anni con successo: rileva in automatico il tipo di dispositivo, ha varie caratteristiche interessanti (checksumming e RAID permettono di evitare bitrot, compressione trasparente, snapshot, …), ma non è un mostro in velocità (è meglio disabilitare il COW per database e macchine virtuali); nilfs (attenzione! il sito ufficiale è http://nilfs.osdn.jp/en/) è molto interessante (snapshotting continuo, bassa latenza), ma poco utilizzato; F2FS è probabilmente un po’ più maturo di NILFS ed ha un maggior throughput, però dipende molto da alcune ipotesi legate al tipo di SSD ed FTL sottostante./]
[/list]

#5

[quote=frafra]

Consigli (configurazione):
[list=1]
]Journaling: non impatta più in maniera sensibile sulla vita dell’SSD, quindi è preferibile lasciarlo attivo/]
]TRIM/discard: può provocare problemi con alcuni firmware, lentezza e problemi di sicurezza se il disco è cifrato; rende più efficiente il lavoro del garbage collector, ma non è obbligatorio utilizzarlo: l’importante è avere un ssd con un buono spazio di overprovisioning o lasciare dello spazio libero/non partizionato/]
]noatime: alcuni programmi specifici potrebbero avere problemi; relatime è l’opzione di default ed è un ottimo compromesso; lazytime è presente a partire dal kernel 4.0 ed è probabilmente la migliore soluzione/]
]Scheduler: cfq è sconsigliato, utilizzare noop o deadline; nei sistemi sia con dischi meccanici sia con SSD è importante fare si che gli hard disk continuino ad utilizzare cfq per ragioni di performance/]
]Spostare più roba possibile in ram: può aver senso a prescindere dal dispositivo di archiviazione che si utilizza (per le performance in primis), ma è bene tenere a mente delle limitazioni di questo sistema (perdita di dati); overlayfs potrebbe essere una tecnologia da sfruttare in questo caso/]
]File system COW (Copy-on-write: niente journaling, si scrive sempre sullo spazio non utilizzato): i filesystem classici sono ottimizzati per gli hard disk; uso btrfs da anni con successo: rileva in automatico il tipo di dispositivo, ha varie caratteristiche interessanti (checksumming e RAID permettono di evitare bitrot, compressione trasparente, snapshot, …), ma non è un mostro in velocità (è meglio disabilitare il COW per database e macchine virtuali); nilfs (attenzione! il sito ufficiale è http://nilfs.osdn.jp/en/) è molto interessante (snapshotting continuo, bassa latenza), ma poco utilizzato; F2FS è probabilmente un po’ più maturo di NILFS ed ha un maggior throughput, però dipende molto da alcune ipotesi legate al tipo di SSD ed FTL sottostante./]
[/list][/quote]
grazie dei consigli

  1. abiliterò subito il journaling (aggiorno: fatto senza problemi)
  2. con TRIM non ho avuto nessun problema quindi mi sa lo lascio così com’è.
  3. provo a cambiarlo da noatime a lazytime (aggiorno: ho provato a cambiarlo in lazytime ma non partiva il sistema; ho dovuto rimettere noatime (come mai???)
  4. sto usando noop adesso ma sono nella configurazione che dici tu cioè SSD (da 250GB) e hard disk (da 500GB). come faccio a discriminare i due scheduler?
  5. quest’estate allora mi sa che installerò da capo fedora 24 con sicuramente BTRFS e magari se mi gira proverò NILFS o F2FS

grazie ancora

#6

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/block/switching-sched.txt?id=HEAD

Puoi usare anche sysctl, quindi al posto di:

# echo SCHEDNAME > /sys/block/DEV/queue/scheduler

…puoi eseguire:

# sysctl -w sys.block.DEV.queue.scheduler=SCHEDNAME

Per rendere persistente la modifica:

# echo "sys.block.DEV.queue.scheduler=SCHEDNAME" >> /etc/sysctl.conf

Valuta tu se usare noop/deadline come default e specificare di utilizzare cfq per i dischi meccanici o il contrario (cfq di default e noop/deadline per le ssd).

Detto ciò, credo che il sistema tenda a configurare questo parametro in automatico. Prima di modificare la configurazione, assicurati che sia effettivamente necessario farlo.

#7

ho controllato notando che è impostato per entrambi i drive su noop
sda = SSD
sdb = Hard Disk

[root@localhost giuseppe]# cat /sys/block/sda/queue/scheduler [noop] deadline cfq [root@localhost giuseppe]# cat /sys/block/sdb/queue/scheduler [noop] deadline cfq

quindi risolvo semplicemente digitando

echo cfq > /sys/block/sdb/queue/scheduler

una seconda domanda. secondo te per l’SSD è meglio noop o deadline?

#8

Semplificando: noop per SSD, deadline per database, cfq per il resto.
Nella realtà dipende molto dal tipo di carico che hai. Inoltre ogni scheduler (a parte noop credo) può essere configurato al meglio (latenza vs throughput, scrittura vs lettura, …)

Non è che hai noop anche su sdb perché hai configurato noop come scheduler di default come opzione al boot?

Per quanto riguarda lazytime: strano, non ho riscontrato problemi, dovrebbe essere tutto a posto (https://lwn.net/Articles/620086/).

#9

[quote=frafra]Semplificando: noop per SSD, deadline per database, cfq per il resto.
Nella realtà dipende molto dal tipo di carico che hai. Inoltre ogni scheduler (a parte noop credo) può essere configurato al meglio (latenza vs throughput, scrittura vs lettura, …)

Non è che hai noop anche su sdb perché hai configurato noop come scheduler di default come opzione al boot?
[/quote]

era configurato al boot è ho provato a modificarlo in qntrambi i modi ma ho dei problemi:
con il primo metodo lo modifica ma poi al riavvio ritorna o su entrambi a noop se ho l’opzione attiva in /etc/default/grub o ritorna cfq se la tolgo.
con il secondo metodo invece ricevo un errore di percorso. te lo riporto

sysctl -w sys.block.sdb.queue.scheduler=cfq sysctl: cannot stat /proc/sys/sys/block/sdb/queue/scheduler: File o directory non esistente

#10

Già, perché lavora su /proc e non su /sys. Puoi usare il sistema con l’echo e metterlo in /etc/rc.local
http://forum.fedoraonline.it/viewtopic.php?pid=235274

#11

ho provato ma niente.

ho creato il file /etc/rc.local e inserito

#!/bin/bash echo cfq > /sys/block/sdb/queue/scheduler

reso eseguibile con chmod +x

e poi abilitato rc-local.service ma ho i seguenti errori

[code]systemctl enable rc-local.service
The unit files have no [Install] section. They are not meant to be enabled
using systemctl.
Possible reasons for having this kind of units are:

  1. A unit may be statically enabled by being symlinked from another unit’s
    .wants/ or .requires/ directory.
  2. A unit’s purpose may be to act as a helper for some other unit which has
    a requirement dependency on it.
  3. A unit may be started when needed via activation (socket, path, timer,
    D-Bus, udev, scripted systemctl call, …).[/code]

ho provato a vedere lo stato ma sembra già attivo.

systemctl status rc-local.service ● rc-local.service - /etc/rc.d/rc.local Compatibility Loaded: loaded (/usr/lib/systemd/system/rc-local.service; static; vendor preset: disabled) Active: inactive (dead)
secondo te come mai?
in più se cambio scheduler dopo il boot non fa niente vero?

#12

Hai ragione. Non saprei.
Se cambi lo scheduler dopo il boot per un device specifico non c’è problema.

#13 
$ cat /usr/lib/systemd/system/rc-local.service

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

# This unit gets pulled automatically into multi-user.target by
# systemd-rc-local-generator if /etc/rc.d/rc.local is executable.
[Unit]
Description=/etc/rc.d/rc.local Compatibility
ConditionFileIsExecutable=/etc/rc.d/rc.local
After=network.target

[Service]
Type=forking
ExecStart=/etc/rc.d/rc.local start
TimeoutSec=0
RemainAfterExit=yes

La riga “ConditionFileIsExecutable=/etc/rc.d/rc.local” fa sì che ti basta creare il file “’/etc/rc.d/rc.local” e renderlo eseguibile per abilitare il servizio.

#14

[quote=arkanoid][code]
$ cat /usr/lib/systemd/system/rc-local.service

This file is part of systemd.

systemd is free software; you can redistribute it and/or modify it

under the terms of the GNU Lesser General Public License as published by

the Free Software Foundation; either version 2.1 of the License, or

(at your option) any later version.

This unit gets pulled automatically into multi-user.target by

systemd-rc-local-generator if /etc/rc.d/rc.local is executable.

[Unit]
Description=/etc/rc.d/rc.local Compatibility
ConditionFileIsExecutable=/etc/rc.d/rc.local
After=network.target

[Service]
Type=forking
ExecStart=/etc/rc.d/rc.local start
TimeoutSec=0
RemainAfterExit=yes
[/code]

La riga “ConditionFileIsExecutable=/etc/rc.d/rc.local” fa sì che ti basta creare il file “’/etc/rc.d/rc.local” e renderlo eseguibile per abilitare il servizio.[/quote]

ok ma purtroppo non va.
ad ogni boot ho lo stesso scheduler (noop) sia per sda (SSD) che per sdb (Hard Disk)

#15

Vediamo questo:

# cat /etc/rc.d/rc.local
#16

Mi inserisco per ricordare che con l’uso di systemd la procedura canonica per fare partire uno script al boot del sistema è la seguente:

[code]Editare un file script.sh con il comando/i che si vuole/vogliono dare.
#!/bin/bash
<your_command_1>
<your_command_2>
,

Creare una ‘service unit’ nome_a_piacere.service in /etc/systemd/system/.
Editare with:

[Unit]
Description=Script name e descrizione

[Service]
ExecStart=/path/to/script.sh

[Install]
WantedBy=multi-user.target

Dire a systemd di startare lo script al boot con:
# systemctl enable something.service.[/code]
Ciò che fa riferimento a rc.local è solo un retaggio del passato.
E’ chiaro che lo sviluppatore di systemd per non creare maggior sconforto negli utenti, dopo aver visto le “ostilità” relative all’uso di systemd stesso, ha preferito lasciare la possibilità di usare anche rc.local, ma io lo sconsiglio vivamente.
Ciao.
Sergio

#17

[quote=idraulico]Mi inserisco per ricordare che con l’uso di systemd la procedura canonica per fare partire uno script al boot del sistema è la seguente:

[code]Editare un file script.sh con il comando/i che si vuole/vogliono dare.
#!/bin/bash
<your_command_1>
<your_command_2>
,

Creare una ‘service unit’ nome_a_piacere.service in /etc/systemd/system/.
Editare with:

[Unit]
Description=Script name e descrizione

[Service]
ExecStart=/path/to/script.sh

[Install]
WantedBy=multi-user.target

Dire a systemd di startare lo script al boot con:
# systemctl enable something.service.[/code]
Ciò che fa riferimento a rc.local è solo un retaggio del passato.
E’ chiaro che lo sviluppatore di systemd per non creare maggior sconforto negli utenti, dopo aver visto le “ostilità” relative all’uso di systemd stesso, ha preferito lasciare la possibilità di usare anche rc.local, ma io lo sconsiglio vivamente.
Ciao.
Sergio[/quote]

provata questa procedura ma niente, in breve
creato file in /opt con il comando da eseguire (in questo caso echo cfq ecc ecc)
creato il service con la descrizione, il percorso del file creato precedentemente e il campo install WantedBy=multi-user.target
e dato il comando systemctl enable cfqHD.service (così ho scelto il nome)
purtroppo non cambia niente. Nessun risultato. I due scheduler all’avvio sono settati o entrambi su noop o entrambi su cfq ( dipende se in /etc/default/grub ho settato o meno elevator=noop

per arkanoid il comando che mi hai postato restituisce che il file non esiste

# cat /etc/rc.d/rc.local cat: /etc/rc.d/rc.local: File o directory non esistente

#18

Fa niente per “rc.local”, seguiamo la strada consigliata da Idraulico che è più elegante.

Credo che, nella sezione “Unit” indicata però, manchi un’importante parametro:

After=local-fs.target

Esso è necessario per far partire il servizio dopo il montaggio dei filesystem.
Se, ancora non funziona, mostraci:

# cat /etc/systemd/system/cfqHD.service
# systemctl status cfqHD.service
# ll /opt
# cat /opt/file_eseguibile

Dove “file_eseguibile” è, ovviamente, lo script bash precedentemente creato.

#19

[quote=arkanoid]Fa niente per “rc.local”, seguiamo la strada consigliata da Idraulico che è più elegante.

Credo che, nella sezione “Unit” indicata però, manchi un’importante parametro:

After=local-fs.target

/
Esso è necessario per far partire il servizio dopo il montaggio dei filesystem.
Se, ancora non funziona, mostraci:

# cat /etc/systemd/system/cfqHD.service
# systemctl status cfqHD.service
# ll /opt
# cat /opt/file_eseguibile

Dove “file_eseguibile” è, ovviamente, lo script bash precedentemente creato.[/quote]
grande adesso funziona :slight_smile:
il problema credo fosse che il file /opt/cfqHD.sh non era eseguibile anche se stranamente l’avevo reso eseguibile. mah vabbè
adesso ho ridato chmod +x /opt/cfqHD.sh e adesso funziona
al boot mi ritrovo noop sull’SSD e cfq per l’hard disk
grazie mille a tutti voi almeno questo problema l’ho risolto.
Rimane sempre quel fastidioso timeout di 4 secondi al boot per la maledetta funzione NCQ mal gestita al boot.
Vorrei tanto sapere cos’hanno cambiato dal kernel dalla 4.1.2 in poi da procurare quest’errore.