Usura SSD sotto linux?

[Mario l'amico del gatto]

c'era una voce, non so se vera o falsa, che diceva che i dischi SSD si
usuravano precocemente sotto linux...
è vera? falsa? ci sono degli accorgimenti?
uso ext4 su debian

[THe_ZiPMaN]

On 04/09/2015 12:29, Mario l'amico del gatto wrote:
> c'era una voce, non so se vera o falsa, che diceva che i dischi SSD si
> usuravano precocemente sotto linux...
> è vera? falsa?

Falsa.

> ci sono degli accorgimenti?

Sì. Montare i device con l'opzione discard e se non ti serve l'orario di
ultimo accesso anche con l'opzione noatime.

> uso ext4 su debian

Non ci sono evidenze di problemi con tale FS su SSD.

--
Flavio Visentin

Scientists discovered what's wrong with the female brain: on the left
side, there's nothing right, and on the right side, there's nothing left

[GabrieleMax]

>> c'era una voce, non so se vera o falsa, che diceva che i dischi SSD si
>> usuravano precocemente sotto linux...
>> è vera? falsa?
>
> Falsa.

Dopo un paio di anni di utilizzo con Debian effettivamente il SSD del
mio HP2170P è saltato sostituito poi in garanzia da HP ma credo faccia
parte della casualità.

> Sì. Montare i device con l'opzione discard e se non ti serve l'orario di
> ultimo accesso anche con l'opzione noatime.

Immagino che queste opzioni siano in qualche file di configurazione e
DuckDuckgo sarà mio amico! :D

>> uso ext4 su debian
>
> Non ci sono evidenze di problemi con tale FS su SSD.

Ok!
Saluti!
GabrieleMax

[Copyleft]

Il 04/09/2015 22:14, GabrieleMax ha scritto:
>
>>> c'era una voce, non so se vera o falsa, che diceva che i dischi SSD si
>>> usuravano precocemente sotto linux...
>>> è vera? falsa?
>>
>> Falsa.
>
> Dopo un paio di anni di utilizzo con Debian effettivamente il SSD del
> mio HP2170P è saltato sostituito poi in garanzia da HP ma credo faccia
> parte della casualità.
>
>> Sì. Montare i device con l'opzione discard e se non ti serve l'orario di
>> ultimo accesso anche con l'opzione noatime.
>
> Immagino che queste opzioni siano in qualche file di configurazione e
> DuckDuckgo sarà mio amico! :D

cat /etc/fstab | grep /
# /etc/fstab: static file system information.
UUID=cf83fe1d-98fc-4550-809f-46177011a18b / ext4
defaults,noatime,discard 0 1 (ssd)


tmpfs /tmp tmpfs
defaults,noatime,mode=1777 0 0

UUID=39817b29-bd47-4994-b041-51708fb53cc6 /home ext4
defaults,noatime 0 1 (meccanico)

[Alessandro Selli]

Il 05/09/2015 06:28, Copyleft ha scritto:

>
> cat /etc/fstab | grep /

Useless use of cat!
http://www.smallo.ruhr.de/award.html


Ciao,


--
Alessandro Selli http://alessandro.route-add.net
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.

[Alessandro Selli]

Il 04/09/2015 13:51, THe_ZiPMaN ha scritto:
> On 04/09/2015 12:29, Mario l'amico del gatto wrote:
>> c'era una voce, non so se vera o falsa, che diceva che i dischi SSD si
>> usuravano precocemente sotto linux...
>> è vera? falsa?
>
> Falsa.
>
>> ci sono degli accorgimenti?
>
> Sì. Montare i device con l'opzione discard e se non ti serve l'orario di
> ultimo accesso anche con l'opzione noatime.

Nei portatili e, in generale, nei sistemi il cui disco può fare
affidamento ad una batteria tampone, si può far lavorare un pochino di
meno il disco disabilitando le barriere in scrittura con l'opzione
barrier=0 o nobarrier e scegliendo per il journal l'opzione
data=writeback. Il rovescio della medaglia è però il maggiore rischio
di ritrovarsi con un filesystem corrotto in caso di arresto catastrofico.

[Copyleft]

Il 05/09/2015 11:31, Alessandro Selli ha scritto:
> Il 05/09/2015 06:28, Copyleft ha scritto:
>
>>
>> cat /etc/fstab | grep /
>
> Useless use of cat!
> http://www.smallo.ruhr.de/award.html
>
>
> Ciao,
>
>

Emo' sta' agguarda' er capello... ;-)

[Sandro kensan]

On 09/04/2015 01:51 PM, THe_ZiPMaN wrote:

> Sì. Montare i device con l'opzione discard e se non ti serve l'orario di
> ultimo accesso anche con l'opzione noatime.

Discard è controverso:

https://wiki.archlinux.org/index.php/Solid_State_Drives#Tips_for_Maximizing_SSD_Performance

Diverse distribuzioni consigliano di usare fstrim in un anacron per il
garbage collection.

--
Sandro kensan www.kensan.it & www.qiqi.it geek site
Saluto gli agenti della NSA - Hello NSA - www.nsa.gov

[enoquick]

Il 05/09/2015 04:39, Alessandro Selli ha scritto:
> Il 04/09/2015 13:51, THe_ZiPMaN ha scritto:
>> On 04/09/2015 12:29, Mario l'amico del gatto wrote:
>>> c'era una voce, non so se vera o falsa, che diceva che i dischi SSD si
>>> usuravano precocemente sotto linux...
>>> è vera? falsa?
>>
>> Falsa.
>>
>>> ci sono degli accorgimenti?
>>
>> Sì. Montare i device con l'opzione discard e se non ti serve l'orario di
>> ultimo accesso anche con l'opzione noatime.
>
> Nei portatili e, in generale, nei sistemi il cui disco può fare
> affidamento ad una batteria tampone, si può far lavorare un pochino di
> meno il disco disabilitando le barriere in scrittura con l'opzione
> barrier=0 o nobarrier e scegliendo per il journal l'opzione
> data=writeback. Il rovescio della medaglia è però il maggiore rischio
> di ritrovarsi con un filesystem corrotto in caso di arresto catastrofico.
>
>
> Ciao,
>
>

Se la la macchina puo usufruire di una batteria o gruppo di continuità
il mio consiglio è di impostare queste opzioni
Ne vale la pena
Anche la ram dovrebbe essere abbastanza grande per fare da cache verso
il disco, in questo modo la differenza di prestazioni si sentono (per
hd meccanici ovviamente)
I crash del kernel per fortuna sono rari se non rarissimi.
L' opzione discard (che serve per gli SSD) è per ora messa ad off per
default in quanto non ancora sufficientemente testata.

[Alessandro Selli]

Non sei il primo a dirmelo, non sarai l'ultimo ad avermelo detto! :-)

[GIulia]

> Emo' sta' agguarda' er capello... ;-)

I bei tempi in cui prima di avviare un processo ci si pensava mezza giornata!!!
Mi ricordo la paura negli occhi del prof quando parlava della duplicazione della memoria dopo la fork
del processo figlio , puro terrore informatico!!
Poi le MMU moderne con il copy on write hanno praticamente azzerato il costo della fork.

Giulia

[enoquick]

altri tempi, e cose come la vfork per aggirarle

[enrico tognoni]

La difesa migliore per i problemi di hardware più recente è una distro
che mette a disposizione il kernel linux aggiornato, tipo gentoo, arch o
debian testing o meglio ancora unstable.
E seguire i consigli delle risposte precedenti.

ciao e buon linux

[GIulia]

> La difesa migliore per i problemi di hardware più recente è una distro che mette a disposizione il kernel linux aggiornato, tipo gentoo, arch o debian testing o
> meglio ancora unstable.
> E seguire i consigli delle risposte precedenti.
>
> ciao e buon linux

I kernel backport sulle stable non ci piacciono ?

Giulia

[enrico tognoni]

On 09/06/15 17:40, GIulia wrote:
> I kernel backport sulle stable non ci piacciono ?
>
> Giulia

La Ferrari giardinetta è una delle mie preferite. :) A saperlo mi
risparmiavo un sacco di guai.

ciao e grazie della info

[bc]

Il 06/09/2015 17:40, GIulia ha scritto:

Non so in generale ma sul mio portatile con uefi disattivo, w7+kubuntu
15.04 si è comportato bene. L'aggiornamento a 10 non mi ha piallato
nulla. Il boot era gestito da grub prima ed è rimaso gestito da grub.
Sono rimasto stupito perchè ero già pronto a ripristinarlo.

[Hybris]

Il 05/09/2015 16:23, Sandro kensan ha scritto:

> Diverse distribuzioni consigliano di usare fstrim in un anacron per il
> garbage collection.
>

ad es. ubuntu ce l'ha in cron.weekly

[Enrico Bianchi]

On Fri, 04 Sep 2015 13:51:02 +0200, THe_ZiPMaN wrote:

> Montare i device con l'opzione discard

Per questa ci sono parecchie voci discordanti, ovvero molti preferiscono
mettere fstrim in crontab settimanale piuttosto che fare un discard
continuo in modo da avere prestazioni migliori

Enrico

[THe_ZiPMaN]

On 10/09/2015 23:33, Enrico Bianchi wrote:
> On Fri, 04 Sep 2015 13:51:02 +0200, THe_ZiPMaN wrote:
>
>> Montare i device con l'opzione discard
>
> Per questa ci sono parecchie voci discordanti,

Rispondo qui anche agli altri che hanno sollevato l'eccezione. Le voci
discordanti sono dovute in massima parte a problemi che c'erano con i
primi dischi SSD. Oggigiorno, su SSD SATA 3.1, non sussistono problemi
di sorta ad utilizzare tale opzione ed è preferibile per migliorare
l'utilizzo del SSD. L'impatto prestazionale è negligibile rispetto ai
benefici che ha l'uso di discard per la durata del disco.
Se si sceglie ftrim (ma anch'esso può scatenare i medesimi problemi se
schedulato in momenti inopportuni) è comunque consigliabile
giornalmente, specie se lo spazio libero sul disco SSD è relativamente poco.

[Alessandro Selli]

Il 11/09/2015 00:42, THe_ZiPMaN ha scritto:

[...]

> è negligibile

ARGH!

[enrico tognoni]

On 09/09/15 15:20, bc wrote:
> Non so in generale ma sul mio portatile con uefi disattivo, w7+kubuntu
> 15.04 si è comportato bene. L'aggiornamento a 10 non mi ha piallato
> nulla. Il boot era gestito da grub prima ed è rimaso gestito da grub.
> Sono rimasto stupito perchè ero già pronto a ripristinarlo.

ma hai dovuto ridisattivare uefi o lo ha lasciato come era?

ciao e grazie

[Enrico Bianchi]

On Fri, 11 Sep 2015 00:42:55 +0200, THe_ZiPMaN wrote:

> Oggigiorno, su SSD SATA 3.1, non sussistono problemi di sorta ad
> utilizzare tale opzione ed è preferibile per migliorare l'utilizzo del
> SSD

Quelli che hanno una SSD Samsung non sono molto d'accordo (ma va beh,
avrebbero problemi anche con fstrim) :)

Enrico

[THe_ZiPMaN]

On 14/09/2015 22:23, Enrico Bianchi wrote:
> Quelli che hanno una SSD Samsung non sono molto d'accordo (ma va beh,
> avrebbero problemi anche con fstrim) :)

Se supportano sata 3.1 anche gli SSD samsung sono OK e supportano il
queued trim. Il modello 850 Pro p.es. non ha problemi [1]

[1] http://hothardware.com/reviews/samsung-ssd-850-pro-128gb-and-1tb-review

[Enrico Bianchi]

On Tue, 15 Sep 2015 00:26:02 +0200, THe_ZiPMaN wrote:

> Se supportano sata 3.1 anche gli SSD samsung sono OK e supportano il
> queued trim. Il modello 850 Pro p.es. non ha problemi

Il fatto e` che proprio per il queued trim, tutte le SSD Samsung sono
state messe in blacklist a causa di problemi con il firmware:

https://www.reddit.com/r/buildapc/comments/3a58s0/
dont_use_linux_on_samsung_ssds/

Enrico

[M_M]

Nota pero` che nella prima riga del messaggio c'e` scritto:
"that isn’t the latest linux kernel".

Mi chiedo invece cosa accadrebbe se provassi a montare un sata 3.1 su un
notebook i5, aggiornato per quanto riguarda il software ma di qualche
annetto fa, com'e` il mio, dove trovo:

description: SATA controller
product: 7 Series Chipset Family 6-port SATA Controller [AHCI mode]

Cioe` mi pare di capire che il controller non sia manco SATA 2 altro che
3.1 . :-/

[Enrico Bianchi]

On Wed, 16 Sep 2015 13:24:59 +0200, M_M wrote:

> Nota pero` che nella prima riga del messaggio c'e` scritto:
> "that isn’t the latest linux kernel".

Guarda, per scrupolo ho controllato anche l'ultimo commit
relativo a quel file[1], e le SSD Samsung serie 8 risultano
ancora in blacklist

Enrico
[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/ata/libata-core.c#n4231

[M_M]

mer, 16 set 2015, 21:43:58, Enrico Bianchi ha scritto:

> Guarda, per scrupolo ho controllato anche l'ultimo commit
> relativo a quel file[1], e le SSD Samsung serie 8 risultano
> ancora in blacklist
>
> Enrico
> [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/ata/libata-core.c#n4231

La data di copyright non e` recente .. cmq per me questo di per se` non
invalida il tuo parere, nel senso che anch'io non molto tempo fa, credo
proprio sul sito di kernel.org, ho letto un comunicato dove si affermava
che gli SSD necessitavano di ulteriori test.
Leggendo a quel tempo cio`, mi feci pero` un'idea personale che non e`
cambiata neppure ora:
kernel.org fa bene a pronunciarsi a quel modo, tenendo presente che in
giro per il mondo ci sono molti computer il cui funzionamento puo`
determinare la vita o la morte di tante persone, ma se invece noi
parliamo di utilizzo di un SSD su un notebook usato ad esempio in ambito
domestico, io penso che allora il discorso cambi totalmente e che se si
dispone di device recenti i problemi siano rarissimi.
Credo quindi che cio` che afferma THe_ZiPMaN in un altro post
corrisponda a verita`, almeno per certi larghi ambiti di utilizzo..
Prova ne e` che spesso qui si leggono richieste di aiuto per una
corretta installazione di un SSD ma io non ricordo nel recente passato
una sola segnalazione di malfunzionamento, usura precoce, ecc. di SSD.

[Enrico Bianchi]

On Sat, 19 Sep 2015 12:41:12 +0200, M_M wrote:

> La data di copyright non e` recente ..

La data di copyright non c'entra molto, quello che ti ho passato e`
l'ultimo commit al file libata-core.c, che sta a significare che le SSD
Samsung serie 800, dal 4 Maggio 2015 ad oggi, non beneficiano del supporto
per il queued trim

Enrico

[Civetta]

Il 15/09/2015 00:26, THe_ZiPMaN ha scritto:
> On 14/09/2015 22:23, Enrico Bianchi wrote:

> Se supportano sata 3.1 anche gli SSD samsung sono OK e supportano il
> queued trim. Il modello 850 Pro p.es. non ha problemi [1]

ho una MB Asus P8Z68 Deluxe di 4 anni fa

Ha incorporati i controller sata

Vorrei prendere un samsung 850 pro

Immagino che sulla mia MB niente sata 3.1


Dovro`prendere un controller nuovo e bloccare quello che c' è

Consigli per un PC domestico ?

grazie

[THe_ZiPMaN]

On 19/09/2015 18:03, Civetta wrote:
>> Se supportano sata 3.1 anche gli SSD samsung sono OK e supportano il
>> queued trim. Il modello 850 Pro p.es. non ha problemi [1]
>
> ho una MB Asus P8Z68 Deluxe di 4 anni fa
>
> Ha incorporati i controller sata
>
> Vorrei prendere un samsung 850 pro
>
> Immagino che sulla mia MB niente sata 3.1
>
>
> Dovro`prendere un controller nuovo e bloccare quello che c' è

No. Importano le specifiche del disco, non del controller del PC. Se il
disco rispetta le specifiche non ci sono problemi ad usarlo con una
versione SATA precedente (in SATA c'è la backward compatibility).

E in ogni caso il queued trim è disabilitato da kernel come fatto notare
da Enrico, quindi non ci sarebbero ugualmente problemi nemmeno se il
disco non lo supportasse (c'è una penalizzazione delle performance ma è
impercettibile nella quotidianità; solo in ambienti enterprise con
dischi che fanno migliaia di IOPS si nota un degrado).

[M_M]

Enrico Bianchi <enrico....@ymail.com> ha scritto:

> La data di copyright non c'entra molto, quello che ti ho passato e`
> l'ultimo commit al file libata-core.c, che sta a significare che le SSD
> Samsung serie 800, dal 4 Maggio 2015 ad oggi, non beneficiano del supporto
> per il queued trim
>
> Enrico

Grazie Enrico, un SSD per ora non l'ho ancora acquistato, perche` nell'attuale
situazione con un notebook i5, 4GB di RAM e HD 500GB a 7200RPM, non ho di che
lamentarmi nello svolgere le normali attivita` web/office/multimedia in casa, pero` un recente danno meccanico al cardine del display credo mi preannunci,
anche se non a brevissima scadenza, un aggiornamento hardware, ed allora e`
meglio che sappia qualcosa di 'sti benedetti SSD ... :-)

Preso atto di cio` che scrivi, mi sorgono ora ancora questi dubbi:

Se io ipoteticamente sostituissi sul mio notebook l'hard-disk con un 'serie 800'
che succederebbe?
io direi, ma ipotizzo ..., che funziona ma vado incontro ad usura precoce, un
po', se il paragone non e` improprio, come mi capita con le chiavette USB che
dopo un determinato uso mi tocca buttare perche` inutilizzabili.

O forse e` quello da te indicato il motivo per cui in questo caso:
https://lists.debian.org/debian-italian/2015/09/msg00130.html
e` stato necessario flashare il firmware?

Scusa, ma questo "quequed trim" non se lo possono implementare on board senza
rompere i maroni al kernel?
Ho letto pure che questi nuovi modelli serie 800 dispongono gia` al loro interno
1 GB di RAM.

Anche se leggo che lo sviluppo degli SSD procede costante e gia` si parla di
SATA 3.2, mi permetto pero` di dire che IMHO sarebbe molto meglio se i
costruttori, ___tutti___, si sforzassero maggiormente nel trovare soluzioni
valide a migliorare l'utilizzo degli SSD, piuttosto che arrovellarsi per come
camuffare al loro interno componenti che i governi, a quanto si legge sui
giornali, usano per spiare.

[THe_ZiPMaN]

On 25/09/2015 21:31, M_M wrote:
> Se io ipoteticamente sostituissi sul mio notebook l'hard-disk con un 'serie 800'
> che succederebbe?
> io direi, ma ipotizzo ..., che funziona ma vado incontro ad usura precoce, un
> po', se il paragone non e` improprio, come mi capita con le chiavette USB che
> dopo un determinato uso mi tocca buttare perche` inutilizzabili.

No. Andresti incontro ad un leggero degrado delle prestazioni. Il
discard lo fa ugualmente, solo non lo può accodare ad altri comandi sata.

> O forse e` quello da te indicato il motivo per cui in questo caso:
> https://lists.debian.org/debian-italian/2015/09/msg00130.html
> e` stato necessario flashare il firmware?
>
> Scusa, ma questo "quequed trim" non se lo possono implementare on board senza
> rompere i maroni al kernel?

Stai facendo un po' di confusione... ognuno fa la sua parte. Il trim è
un comando sata che viene dato al disco per indicare che un certo
settore è libero, quindi il disco viene informato ed agisce di
conseguenza. Il queued trim è semplicemente il comando trim accodato ad
altri comandi SATA. Alcuni dischi non lo supportano e quindi il kernel
mette in blacklist il comando. Questo non vuol dire che il kernel non
invia i trim, vuol solo dire che quando li manda non li accoda ad altri
comandi sata.

> Ho letto pure che questi nuovi modelli serie 800 dispongono gia` al loro interno
> 1 GB di RAM.

In tal caso accertati che siano power protected.

> Anche se leggo che lo sviluppo degli SSD procede costante e gia` si parla di
> SATA 3.2,

SATA è lo standard di comunicazione con i dispositivi di storage; non ha
attinenza con SSD se non per il fatto che anche gli SSD devono
rispettare gli standard.

> mi permetto pero` di dire che IMHO sarebbe molto meglio se i
> costruttori, ___tutti___, si sforzassero maggiormente nel trovare soluzioni
> valide a migliorare l'utilizzo degli SSD,

Già lo fanno. La differenza tra il mio vecchio SSD Samsung 830 Pro e il
mio nuovo Sandisk Extreme Pro è evidentissima.

> piuttosto che arrovellarsi per come
> camuffare al loro interno componenti che i governi, a quanto si legge sui
> giornali, usano per spiare.

Non serve arrovellare nulla. E' da una vita (almeno 10 anni) che i
dischi sono a tutti gli effetti dispositivi programmabili e quindi
possono essere usati per eseguire codice (anche malevolo).

[Alessandro Selli]

Il 26/09/2015 02:45, THe_ZiPMaN ha scritto:

> Non serve arrovellare nulla. E' da una vita (almeno 10 anni) che i
> dischi sono a tutti gli effetti dispositivi programmabili e quindi
> possono essere usati per eseguire codice (anche malevolo).

Incluso il farci girare Linux: http://spritesmods.com/?art=hddhack

[Civetta]

Il 20/09/2015 15:37, THe_ZiPMaN ha scritto:


> E in ogni caso il queued trim è disabilitato da kernel come fatto notare
> da Enrico, quindi non ci sarebbero ugualmente problemi nemmeno se il
> disco non lo supportasse (c'è una penalizzazione delle performance ma è
> impercettibile nella quotidianità; solo in ambienti enterprise con
> dischi che fanno migliaia di IOPS si nota un degrado).

mi è arrivato l' 850 pro

Ho letto un po' in giro ed ho scoperto che almeno a febbraio 2015 c' era
un problema di firmware. Si riferiva al trim ?
Non è ancora stao risolto?

come faccio a conoscere il firmware installato usando un cd con gparted ?


Per installare nuovo firmware solo progamma win e Mac. Per altro vuole
una alta risoluzione dello schermo

Io win l' ho solo in macchine virtuali virtualbox allora mi è venuto in
mente un "trucco" che forse è una bestialità: metto l' 850 pro in un
lettore dischi esterno USB e installo il firmware da win in virtualbox.

Il tutto mi lascia perplesso. Se monto un pc nuovo con dischi vuoti devo
per installare il firmware prima installare win ?

A me sembra una operazone da fare prima di installare qualsiasi S.O. e
quindi da fare con un cd/usb con il quale fare il boot.

[enricoT]

On 04/09/2015 12:29, Mario l'amico del gatto wrote:
> c'era una voce, non so se vera o falsa, che diceva che i dischi SSD si
> usuravano precocemente sotto linux...
> è vera? falsa? ci sono degli accorgimenti?
> uso ext4 su debian

Domanda, se volessi caricare un database scacchistico di 60giga di
endgame risolti, e usare un hd esterno ssd di cosa dovrei preoccuparmi?
In pratica sarebbe scritto una volta l'ssd, al momento della generazione
del database, e poi aperto in sola lettura per leggere se una
determinata posizione finale fosse di 6 pezzi sarebbe automaticamente
letta su quel database, quindi migliaia di letture a mossa o milioni
ogni volta, non una scrittura ad accensione, una sola scrittura in
assoluto, quindi una volta sola scritto miliardi di volte letto ogni
volta che l'engine scacchistica gioca.
La lettura nell'ssd usura? Un hd esterno ssd è più veloce dell'hd sata o
non avrebbe senso?

ciao e grazie

[Joe]

enricoT <stefy...@gmail.com> wrote:
>
> La lettura nell'ssd usura? Un hd esterno ssd è più veloce dell'hd sata o
> non avrebbe senso?

Ti dico la mia:

- non so se la sola lettura ripetuta in modo così massiccio accorci
pesantemente la vita dell'ssd, quindi qui passo.
A naso però direi che se per esempio lo montassi in sola lettura
dopo aver caricato il database la prima volta e il tutto funzionasse
senza necessità di avere permessi in scrittura... bè la butto lì
ma a buon senso non ci vedrei usura.
Almeno da quello che ho capito io è la scrittura e riscrittura che
va a pesare sulla vita del dispositivo, non la lettura.
Però ripeto aspetta qualche altra risposta.

- sul discorso velocità immagino che tu debba fare una considerazione
sui colli di bottiglia tra la CPU e il database che sta sul SSD.
Anche qui andando a naso se colleghi il tutto via USB-2 secondo me ha
poco senso, converrebbe in qualche modo collegare l'SSD usando
un'interfaccia più spinta. Altrimenti penso proprio che un con un HDD
meccanico non si impieghi molto più tempo.
Però anche qui aspetta conferme.

In ogni caso se parliamo di un PC fisso cerca di far saltare fuori
un'interfaccia SATA...

[not1xor1]

Il 13/10/2015 20:46, enricoT ha scritto:

> Domanda, se volessi caricare un database scacchistico di 60giga di
> endgame risolti, e usare un hd esterno ssd di cosa dovrei
> preoccuparmi?

considerando l'impiego che hai descritto (nella parte non quotata) il
disco rimarrà alimentato abbastanza a lungo per permettere l'eventuale
refresh dei dati
(<http://superuser.com/questions/923081/ssd-data-refresh>) e data la
scarsa entità delle conseguenti scritture dovrebbe essere in grado di
funzionare per decenni

riguardo la velocità di un disco esterno SSD rispetto ad un HDD
dipende essenzialmente dal tipo di connessione

se si tratta di USB2 il vantaggio sarà ridotto, mentre con una
connessione USB3 ti avvicinerai molto alla velocità di un SSD montato
su SATA

--
bye
!(!1|1)

[Valerio Vanni]

On Tue, 13 Oct 2015 17:18:56 +0200, Civetta <Civ...@Athena.gr> wrote:

>come faccio a conoscere il firmware installato usando un cd con gparted ?

Apri una shell e usi "hdparm -i" (o "hdparm -I").

>Per installare nuovo firmware solo progamma win e Mac. Per altro vuole
>una alta risoluzione dello schermo
>
>Io win l' ho solo in macchine virtuali virtualbox allora mi è venuto in
>mente un "trucco" che forse è una bestialità: metto l' 850 pro in un
>lettore dischi esterno USB e installo il firmware da win in virtualbox.

E' improbabile che venga aggiornato su un adattatore USB.


--
Ci sono 10 tipi di persone al mondo: quelle che capiscono il sistema binario
e quelle che non lo capiscono.

[Civetta]

Il 14/10/2015 13:42, Valerio Vanni ha scritto:
> On Tue, 13 Oct 2015 17:18:56 +0200, Civetta <Civ...@Athena.gr> wrote:
>
>> come faccio a conoscere il firmware installato usando un cd con gparted ?
>
> Apri una shell e usi "hdparm -i" (o "hdparm -I").

ecco cosa dice questo sito che da quanto capisco ha lanciato per primo
l' allarme "trim"

https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/

-------------------------

sudo hdparm -I /dev/sdc | grep -i trim
* Data Set Management TRIM supported (limit 8 blocks)

However executing the Samsung magician software on Ubuntu 14.04 returns
the following error:

ERROR : This feature is not supported for disks connected to LSI RAID
HBA Cards.
-------------------------

a chi credere ? a hdparm o al Magician samsung che per altro è un prg
win e non so come l' abbia eseguito Ubuntu ( wine??)

[THe_ZiPMaN]

On 14/10/2015 17:04, Civetta wrote:
> a chi credere ? a hdparm o al Magician samsung

hdparm

Come detto il disco supporta trim e anche queued trim. In ogni caso
quest'ultimo è disabilitato da kernel, quindi vai sereno.