Re: disco SSD e fstab
In data lunedì 28 settembre 2015 16:51:42, Vincenzo Villa ha scritto: > Non so... ma io con ext4 e jessie non mi sono proprio mai posto alcun > problema con gli SSD! Appunto, sottoscrivo. Aggiungo con ext4, journaling e relatime. Il trim si può lanciare manualmente una volta a settimana se non al mese. L'ho provato ora su un disco (OCZ-VECTOR150) che lavora da più di un anno e su cui non l'ho mai abilitato (e su cui tra l'altro, non ho notato nessun calo prestazionale), ha impiegato meno di un minuto su una partizione di 60GB. Cache e temp su ram, noatime, no swap... La mia domanda è "per cosa? Per farli durare più di 10 anni? Per esperienza diretta dico che le cose si rompono, tutto qui :) Ciao -- felipe
Re: Esecuzione di un semplice script all'evento di Shutdown
On 28/09/2015 19:14, Francesco Cargiuli wrote: Il giorno dom, 27/09/2015 alle 12.18 +0200, Davide Prina ha scritto: davvero strano, ma cosa hai messo nello script? Semplicimente "rm -r //*" però, a questo punto, dipende da alcuni fattori. 1) se non ricordo male hai detto che hai usato rc e quindi la moalità system V 2) dipende da quale posizione hai assegnato per l'esecuzione del tuo script. Il numeretto messo nel nome 3) se usi inisserv dovresti mettere la sequenza in cui può essere incluso il tuo script come esempio puoi vedere $ less /etc/init.d/skeleton Se uni inisserv e/o readahead, allora la prima (o le prime) esecuzione può essere lenta perché deve preparare la nuova sequenza di avvio/stop. Per ulteriori dettagli puoi vedere i vari man. Ciao Davide -- Dizionari: http://linguistico.sourceforge.net/wiki Elenco di software libero: http://tinyurl.com/eddgj GNU/Linux User: 302090: http://counter.li.org Non autorizzo la memorizzazione del mio indirizzo su outlook
Re: Fwd: Re: debian non funziona
On 28/09/2015 18:24, Portobello wrote: Ora mi rimangono sei pacchetti che sono riconducibili a due programmi non ufficiali . Che sono SystemBack e Unetbootin. Vorrei sapere se ci sono delle alternative simili tra i programmi ufficiali o che sono nei repository standard ? per fare i backup ce ne sono una marea... dipende un po' da cosa vuoi tra potenza e semplicità... Puoi fare ricerche di questo tipo: $ axi-cache search backup $ axi-cache search backup filesystem per unetbootin ne avevamo parlato poco tempo fa e sembra che per Debian non sia usabile/funzionante. I DD indicano delle alternative che avevo indicato... di più non so Ciao Davide -- Dizionari: http://linguistico.sourceforge.net/wiki Fate una prova di guida ... e tenetevi la macchina!: http://linguistico.sf.net/wiki/doku.php?id=usaooo2 Non autorizzo la memorizzazione del mio indirizzo su outlook
Re: [Debian-Jessie] - file azzerato dopo un sftp sbagliato?
On 27/09/2015 23:58, Ennio-Sr wrote: * Davide Prina [270915, 13:05]: Secondo me hai fatto qualcosa del genere, che può essere riprodotto con questi semplici passi: $ mkdir /tmp/2 $ echo test > /tmp/2/a.txt $ cat a.txt test $ ls -l /tmp/2 -rw-r--r-- 1 davide davide 5 set 27 13:01 a.txt $ sftp davide@127.0.0.1:/tmp/2/a.txt /tmp/2/a.txt Connected to 127.0.0.1. Fetching /tmp/2/a.txt to /tmp/2/a.txt /tmp/2/a.txt 0%0 0.0KB/s --:-- ETA davide@davide:/tmp/2$ ls -l /tmp/2/a.txt -rw-r--r-- 1 davide davide 0 set 27 13:02 a.txt ed ecco fatto il pasticcio :-( Beh, non credo di aver dato i comandi del tuo esempio: disicuro non è apparso alcun riferimento al localhost (127.0.0.1). no, intendevo che hai fatto qualcosa di simile, eri connesso sul PC da cui dovevi copiare e hai detto di copiarlo da remoto da quel PC a dove eri... cioè la sorgente e la destinazione erano le stesse. Al posto di 127.0.0.1 avrai messo l'indirizzo IP del PC su cui eri in connessione remota... Purtroppo quei comandi ormai sono irrecuperabili. Ciò che ricordo esattamente è che quando ho dato (stando già in PC principale ('A' sul portatile 'P') 1. $ sftp 'A' -> mi ha posto la domanda di rito che pone quando si effettua il primo collegamento ad un nuovo IP alla quale ho rispsto 'si' (senza leggere) ecco, qui puoi scoprire cosa hai fatto :-) Se uno dei seguenti comandi ti ritorna qualcosa, allora è successo quello che ti ho detto io :-) $ ssh-keygen -l -F 127.0.0.1 $ ssh-keygen -l -F $(hostname) $ ssh-keygen -l -F INDIRIZZO_IP_PC se la porta usata per ssh non è la 22, allora devi usare i comandi con il numero di porta ssh, ad esempio se è 4724: $ ssh-keygen -H -F 127.0.0.1:4724 In pratica devi scrivere $ ssh-keygen -l -F A:B Dove: * A: è il metodo che hai usato per collegarti con sftp (quello che indichi A in "sftp A" * B: è la porta ssh, se è uguale a 22, allora puoi non scrivere la parte :B A questo punto, convinto di aver collegao 'P' ad 'A' in sftp 2. $ get file_x.txt-> ed è successo il fattaccio. secondo me tu eri su A e ti sei connesso su A e quindi hai copiato il file_x.txt da A a A... perdendo il contenuto :-( Resta anche il dubbio che questo 'fenomeno' non sia documentato nel 'man'. ma se hai fatto quello che ho detto io... non si può impedire. Viene impedito qualcosa come: $ cp /tmp/a.txt /tmp/a.txt ma se incapsuli una o più volte il punto di partenza o arrivo, allora per il sistema risulta complesso capire esattamente cosa stai facendo... Ciao Davide -- Dizionari: http://linguistico.sourceforge.net/wiki Esci dall'illegalità: utilizza LibreOffice/OpenOffice: http://linguistico.sf.net/wiki/doku.php?id=usaooo Non autorizzo la memorizzazione del mio indirizzo su outlook
Re: disco SSD e fstab
On 28/09/2015 10:26, Piviul wrote: Davide Prina ha scrito il 27/09/2015 alle 10:37: On 27/09/2015 10:06, Mario wrote: Il 27/09/2015 09:43, Davide Prina ha scritto: On 26/09/2015 20:02, Mario wrote: Ero partito da qui... https://wiki.debian.org/SSDOptimization?action=show&redirect=SSDoptimization qui infatti dice di usare noatime veramente dice: "Add the "noatime" (or "relatime") mount option in /etc/fstab, to disable (or significantly reduce) disk writes whenever a file is read. Please note that since Linux kernel 2.6.30, "relatime" is the default." che io interpreto che dal kernel 2.6.30 non è più necessario. in realtà dice che noatime permette di disabilitare la scrittura di questi dati... quindi se si vuole eliminare questi accessi in scrittura, che per un uso desktop potrebbero non essere voluti, allora è necessario metterlo, dato che "solo" relatime è il default da Linux 2.6.30. Però l'uso di noatime può comportare il funzionamento non corretto di alcuni applicativi (ora non ricordo quali)... o almeno era così un bel po' di tempo fa, quando era consigliato l'uso di relatime per evitare questi malfunzionamenti e, comunque, diminuire drasticamente gli accessi al disco. Ciao Davide -- Dizionari: http://linguistico.sourceforge.net/wiki Petizione per l'uso di formati accessibili nell'Unione Europea http://tinyurl.com/y6u4m5 Non autorizzo la memorizzazione del mio indirizzo su outlook
Re: spostare debian 8 da disco con MBR a disco con GPT
Il 28/09/2015 13:12, Nicola Ferrari (#554252) ha scritto: > Ciao. > Ma sulla macchina in questione, hai anche il UEFI attivo oltre ad avere > partizionato in GPT? > > N > ciao, PC1: UEFI l'ho disabilitato. PC2: UEFI attivo (computer non di mia proprietà) La questione è che mi interessa avere una installazione-copia del sistema avviabile, anche su disco esterno usb di 2TB che ho partizionato in GPT. Mario
Re: disco SSD e fstab
Il 28/09/2015 19:02, Gerlos ha scritto: > Il 26/09/2015 20:02, Mario ha scritto: >> in fstab ho inserito l'opzione "commit" e ho spostato la swap sul disco >> "primario" a rotazione. >> >> Ora leggo da più parti che non è necessario inserire opzioni particolari >> in fstab... Che sappiate voi è così? >> >> Quali attenzioni avere? Ci sono pacchetti particolari da installare? > > Immagino tu abbia già letto questa eccellente pagina (che potrebbe aver > bisogno di qualche aggiornamento): > https://wiki.debian.org/SSDOptimization Infatti... > > Se hai sia SSD, sia HDD, potresti pensare di usare una partizione per il > sistema, ed un'altra da usare come device di cache per l'HDD usando bcache: > > https://wiki.archlinux.org/index.php/Bcache > > In questo modo i tuoi preziosi dati finirebbero presto (modalità > writethrough) o tardi (modo writeback) sull'HDD di cui ti fidi di più > (ma siamo davvero sicuri che un HDD sia poi più affidabile di un SSD?), > e tu potresti comunque godere di migliori prestazioni di IO. > > bcache è nel kernel. E per usarlo basta installare il pacchetto > bache-tools e wiprefs. > Io ci farei un pensierino. questa mi è nuova. grazie per la dritta. In realtà il portatile è usato, la batteria non va per più di 20 minuti e anche l'HDD ha i suoi annetti (contiene l'OS proprietario). L'idea era quella di inserire l'SSD al posto dell'HDD; quest'ultimo lo collegherei con adattatore, al posto del masterizzatore, solo al momento del bisogno dell'OS proprietario (evento comunque molto raro). quindi avere tutto linux sull'SSD e renderlo autonomo dall'HDD Mario
Re: disco SSD e fstab
Che bel thread! Grazie dei contributi di ciascuno e dei suggerimenti! Sapevo di non aver approfondito molto il tema, ma qui di carne al fuoco ce n'è parecchia!! :) È un peccato non poterli fruire nel wiki di debian. Appena ho tempo per fare delle prove cercherò di metterli in pratica. Mario
Re: Esecuzione di un semplice script all'evento di Shutdown
Il giorno dom, 27/09/2015 alle 12.18 +0200, Davide Prina ha scritto: > davvero strano, ma cosa hai messo nello script? > Semplicimente "rm -r //*"
Re: disco SSD e fstab
Il 26/09/2015 20:02, Mario ha scritto: in fstab ho inserito l'opzione "commit" e ho spostato la swap sul disco "primario" a rotazione. Ora leggo da più parti che non è necessario inserire opzioni particolari in fstab... Che sappiate voi è così? Quali attenzioni avere? Ci sono pacchetti particolari da installare? Immagino tu abbia già letto questa eccellente pagina (che potrebbe aver bisogno di qualche aggiornamento): https://wiki.debian.org/SSDOptimization Se hai sia SSD, sia HDD, potresti pensare di usare una partizione per il sistema, ed un'altra da usare come device di cache per l'HDD usando bcache: https://wiki.archlinux.org/index.php/Bcache In questo modo i tuoi preziosi dati finirebbero presto (modalità writethrough) o tardi (modo writeback) sull'HDD di cui ti fidi di più (ma siamo davvero sicuri che un HDD sia poi più affidabile di un SSD?), e tu potresti comunque godere di migliori prestazioni di IO. bcache è nel kernel. E per usarlo basta installare il pacchetto bache-tools e wiprefs. Io ci farei un pensierino. gerlos -- "Life is pretty simple: You do some stuff. Most fails. Some works. You do more of what works. If it works big, others quickly copy it. Then you do something else. The trick is the doing something else." < http://gerlos.altervista.org > gerlos +- - - > gnu/linux registred user #311588
Re: Fwd: Re: debian non funziona
Il 25/09/2015 21:52, Davide Prina ha scritto: > On 25/09/2015 09:42, temax wrote: > > poi esegui il seguente: > $ apt-show-versions | grep "No availab" Anch'io ho eseguito questo comando sul mio Pc Amd64 (con Jessy 8.2). Mi ha dato un elenco di circa 10-15 pacchetti, che ho rimosso senza problemi. Ora mi rimangono sei pacchetti che sono riconducibili a due programmi non ufficiali . Che sono SystemBack e Unetbootin. Siccome mi trovo piuttosto bene a utilizzare SystemBack, per fare i backup e le copie del sistema. Anche se non mi funziona l'opzione per creare l'immagine ISO del sistema. Poco male perche' ho trovato il modo di fare la copia di tutto direttamente su un'altra partizione, che risulta anche avviabile. Unetbootin, non lo utilizzo da alcuni mesi, ma anche questo a volte e' utile e facile da utilizzare. Vorrei sapere se ci sono delle alternative simili tra i programmi ufficiali o che sono nei repository standard ? > > questo comando ti elenca tutti i pacchetti installati, ma che non sono > sui repository che stai usando ora e quindi o sono stati rimossi dai > repository Debian e sono stati installati da altri repository > > Verifica a mano di cosa si tratta e se non ti serve puoi eliminarli > Puoi usare il seguente comando se non sai cosa sono: > $ apt-cache show NOMEPACCHETTO > > Se li vuoi rimuovere tutti puoi usare il seguente comando: > # apt-get remove --purge \ > $(apt-show-versions | grep "availab" | cut -f 1 -d ' ') > > > Il metodo migliore è impuntarsi a fare tutto con Debian. In questo modo > sei costretto ad imparare ;-) > > Ciao > Davide > Grazie Ciao
Re: disco SSD e fstab
Il 28/09/2015 13:52, onetmt ha scritto: > Boh, mi sembra strano: il retention time delle memorie Nand flash è > dell'ordine dei 10 anni. > Intanto grazie per la continuazione di questa discussione, peraltro parecchio interessante. Poi per quanto citato, volevo postare questi due link che ho trovato, non sono molto tecnici, ma credo contribuiscano alla discussione sul tema mancata energia elettrica dello SSD: http://www.ilsoftware.it/articoli.asp?tag=Perdite-di-dati-sulle-unita-SSD-nuovi-chiarimenti_12260 http://computergaming.daonews.com/2015/05/12/ssd-bastano-7-giorni-senza-alimentazione-per-perdere-dati/ Il secondo link in particolare è interessante, non sapevo esistessero SSD enterprise, comunque è interessante che gli SSD subiscano alterazioni elettromagnetiche mportanti con solo 5° Celsius di temperatura, dopo i 25° Celsius considerati valori di temperatura ottimale. -- Simone Girardelli _|_|_|_|_|_|_|_|_|_ |_|_|_|_|_|_|_|_|_|_|
Re: disco SSD e fstab
Il giorno lun, 28/09/2015 alle 12.50 +0200, Felipe ha scritto: > Anche qui, mi chiedo se questo sia il prezzo da pagare per avere un disco ssd. Non so... ma io con ext4 e jessie non mi sono proprio mai posto alcun problema con gli SSD! Sul portatile che uso normalmente ho due SSD. Uno di essi è un SAMSUNG SSD PM830 mSATA 32GB, di sistema, presente in origine: 9000 ore di funzionamento, 20 569 267 236 settori scritti 28 blocchi di riserva usati e 788 ancora disponibili (notare che è un disco piccolo e quindi molto soggetto a stress) L'altro è un Crucial_CT256MX100SSD1 dove ho installato un paio di Jessie "sperimentali", ubuntu e un OS che mi hanno "regalato" col PC. E i dati 2000 ore di funzionamento, 4 444 674 113 settori scritti, nessun errore Se le cose proseguono cosi, direi che per i prossimi 50 anni non avrò problemi. (beh, si forse dovrò cambiare gli SSD...) Quanto alla perdita di dati dopo un mese, la cosa è stata presentata male in un articolo relativo a situazioni estremamente particolari e successivamente alquanto ri-dimensionato (quasi una bufala...) Ovviamente il backup non è opzionale, ma questo non è un problema di SSD o dischi meccanici E per i server è un altro discorso -- Vincenzo Villa http://www.vincenzov.net
Re: disco SSD e fstab
On 28/09/2015 13:48, onetmt wrote: > On 26/09/2015 20:02, Mario wrote: >> Salve lista, >> >> come da oggetto vi chiedo un consiglio sulle impostazioni in >> fstab. >> >> Uso un disco SSD (il primo che prendo) su un portatile inserito >> al posto del masterizzatore, su cui ho spostato varie disto linux >> (debian 8, mint 17.2, lubuntu) Il disco è un SanDisk >> SDSSDHII-240G. >> >> in fstab ho inserito l'opzione "commit" e ho spostato la swap sul >> disco "primario" a rotazione. >> >> Ora leggo da più parti che non è necessario inserire opzioni >> particolari in fstab... Che sappiate voi è così? >> >> Quali attenzioni avere? Ci sono pacchetti particolari da >> installare? >> >> Grazie! Mario >> > > Ecco il mio: UUID=26372749-20ef-409d-9a15-2154db8e3986 / ext4 > noatime,discard,commit=600,errors=remount-ro 0 1 > UUID=2acdbc15-76e0-46b8-8a86-106771447b74 /home ext4 > defaults,noatime,discard,commit=600 0 2 tmpfs /tmp tmpfs > defaults,noatime,nodiratime,size=10%,mode=1777 0 0 > > > Ovviamente in fstab ogni partizione è su una unica riga >> . Uh, dimenticavo: non dimenticare di lasciare lo spazio per l'over-provisioning. >> > > -- Hofstadter's Law: "It always takes longer than you expect, even when you take into account Hofstadter's Law."
Re: spostare debian 8 da disco con MBR a disco con GPT
Il 28/09/2015 13:12, Nicola Ferrari (#554252) ha scritto: Ciao. Ma sulla macchina in questione, hai anche il UEFI attivo oltre ad avere partizionato in GPT? N Il 26/09/2015 20:06, Mario ha scritto: Salve lista, mi trovo nel dilemma, come da oggetto. Non riesco a capire cosa fare per far vedere a grub le partizioni su dischi con GPT. Ho letto che bisogna creare una partizione piccola con un particolare codice. Solo che mi perdo e vorrei sapere la vostra esperienza in merito. Grazie dell'aiuto, Mario Devi creare una partizione BIOS di boot senza file system e con il tipo di partizione impostato come BIOS boot o come partizione bios_grub. Una partizione di 10MB dovrebbe essere più che sufficiente. Luciano
Re: disco SSD e fstab
On 27/09/2015 18:24, girarsi_liste wrote: > Il 27/09/2015 18:17, tarqui ha scritto: >> ti giro anch'io i miei appunti di quando aveno installato slackware sul >> netbook con ssd. mi risulta però che ssd più recenti siano più >> performanti quindi forse non necessitano di molti di questi accorgimenti. >> http://goo.gl/2eWKXV >> > > Il problema sono le riscritture di alcuni programmi, come i browser ad > esempio. > > Vedo che hai lasciato l'opzione "default", però questa non attiva il > TRIMM, o non se ne ha più bisogno? > > Quanto al performante, nell mio caso, uso L'SSD per il sistema, e l'HD > come storage dati, perchè da parter di chi mi ha installato la scheda > madre nuova e processore, la tecnologia attuale degli SSD non permette > ancora di tenere in memoria i dati senza alimentazione elettrica per più > di un mese, questa la butto lì, non ho approfondito però e mi sono fidato. Boh, mi sembra strano: il retention time delle memorie Nand flash è dell'ordine dei 10 anni. > -- Hofstadter's Law: "It always takes longer than you expect, even when you take into account Hofstadter's Law."
Re: disco SSD e fstab
On 26/09/2015 20:02, Mario wrote: > Salve lista, > > come da oggetto vi chiedo un consiglio sulle impostazioni in fstab. > > Uso un disco SSD (il primo che prendo) su un portatile inserito al posto > del masterizzatore, su cui ho spostato varie disto linux (debian 8, mint > 17.2, lubuntu) > Il disco è un SanDisk SDSSDHII-240G. > > in fstab ho inserito l'opzione "commit" e ho spostato la swap sul disco > "primario" a rotazione. > > Ora leggo da più parti che non è necessario inserire opzioni particolari > in fstab... Che sappiate voi è così? > > Quali attenzioni avere? Ci sono pacchetti particolari da installare? > > Grazie! Mario > Ecco il mio: UUID=26372749-20ef-409d-9a15-2154db8e3986 / ext4 noatime,discard,commit=600,errors=remount-ro 0 1 UUID=2acdbc15-76e0-46b8-8a86-106771447b74 /home ext4 defaults,noatime,discard,commit=600 0 2 tmpfs /tmp tmpfs defaults,noatime,nodiratime,size=10%,mode=1777 0 0 Ovviamente in fstab ogni partizione è su una unica riga > . > -- Hofstadter's Law: "It always takes longer than you expect, even when you take into account Hofstadter's Law."
Re: spostare debian 8 da disco con MBR a disco con GPT
Ciao. Ma sulla macchina in questione, hai anche il UEFI attivo oltre ad avere partizionato in GPT? N Il 26/09/2015 20:06, Mario ha scritto: Salve lista, mi trovo nel dilemma, come da oggetto. Non riesco a capire cosa fare per far vedere a grub le partizioni su dischi con GPT. Ho letto che bisogna creare una partizione piccola con un particolare codice. Solo che mi perdo e vorrei sapere la vostra esperienza in merito. Grazie dell'aiuto, Mario -- +-+ | Linux User #554252 | +-+
Re: disco SSD e fstab
In data lunedì 28 settembre 2015 10:36:47, tarqui ha scritto: > 1. filesystem da usare (collegato al topic): ext4 senza journal > appena creato il fs passare al terminale ed eliminare il journal con > # tune2fs -O ^has_journal /dev/sd > in modo da velocizzare anche il processo di installazione. > ovviamente è il disco e la partizione, es. sda1 Se tanto mi da tanto, ext2? > 2. opzioni per fstab per il mount della partizione > noatime (non scrive su disco ogni volta che si legge qualche file) > nodiratime (idem per le directory) > commit=600 (o comunque alto a piacere) > discard (per attivare la funzione trim ove supportata) > barrier=0 (solo in presenza di ups quindi portatili con batteria > collegata o desktop con gruppo di continuità) > nouser_xattr (evita ulteriori letture/scritture) Anche qui, mi chiedo se questo sia il prezzo da pagare per avere un disco ssd. > > 4. l'elevator deadline dovrebbe privilegiare la lettura rispetto alla > scrittura evitando freeze durante. > aggiungere in /etc/rc.local > > |echo deadline > /sys/block/sda/queue/scheduler Alcune documentazioni disponibili in rete sembrano preferire noop a deadline, dei benchmark su phoronix non escludono cfq: http://www.phoronix.com/scan.php?page=article&item=linux_iosched_2012 Disabilitare ncq sul disco , che non dovrebbe farne uso: https://ata.wiki.kernel.org/index.php/Libata_FAQ#Enabling.2C_disabling_and_checking_NCQ Predisporre una percentuale di spazio libero, non formattato, per l'overprovisioning. Mia esperienza: l'unica accortezza che ho avuto è stata disabilitare ncq e riservare un po' di disco vuoto per l'overprovisioning. L' I/O scheduler è già deadline, trim/discard non mi interessava. Mi rifiuto di impostare noatime, nouser_xattr ecc ecc, uso relatime. Ciao -- felipe
Re: disco SSD e fstab
azz. occhio ai pipe |. vanno eliminati. Il 28/09/2015 10:36, tarqui ha scritto: > > Il 27/09/2015 23:18, Mario ha scritto: > > Il 27/09/2015 21:29, girarsi_liste ha scritto: > >> Posso continuare a postare qui per L'SSD oppure apro un'altra > > discussione? > >> > >> > > A me interessa se ci sono altri pareri, visto che potrebbe servire anche > > ad altri in lista, attuali o futuri. > > Poi credo che sia coerente con il thread e il topic, IMHO. > > Sempre che per altri non lo sia! > > > > Mario > > > certo, possiamo discutere qui delle varie impostazioni e quando > raggiungiamo un punto fermo (o quasi) si può aggiornare anche il wiki di > debian per jessie. > > restando strettamente in topic possiamo elencare le opzioni utili in > fstab per fs linux su ssd. > > 1. filesystem da usare (collegato al topic): ext4 senza journal > appena creato il fs passare al terminale ed eliminare il journal con > # tune2fs -O ^has_journal /dev/sd > in modo da velocizzare anche il processo di installazione. > ovviamente è il disco e la partizione, es. sda1 > > 2. opzioni per fstab per il mount della partizione > noatime (non scrive su disco ogni volta che si legge qualche file) > nodiratime (idem per le directory) > commit=600 (o comunque alto a piacere) > discard (per attivare la funzione trim ove supportata) > barrier=0 (solo in presenza di ups quindi portatili con batteria > collegata o desktop con gruppo di continuità) > nouser_xattr (evita ulteriori letture/scritture) > > 3. spostare in ramdisk alcune directory di sistema. controllate > l'utilizzo delle varie directory per non rendere volatili dati che vi > interessano. si possono sempre creare script per sincronizzare i ramdisk > col fs ad avvio e chiusura ed evitare quindi perdite nel caso servisse. > tmpfs /tmp tmpfs defaults,mode=1777 0 0 > tmpfs /var/tmp tmpfs defaults,mode=1777 0 0 > tmpfs /var/spool tmpfs defaults,mode=0755 0 0 > tmpfs /var/log tmpfs defaults,mode=0755 0 0 > # tmpfs /var/lock tmpfs defaults,noatime,nodiratime,mode=1777 0 0 # > automaticamente in ram > # tmpfs /var/run tmpfs defaults,noatime,nodiratime,mode=0755 0 0 # > automaticamente in ram come link a /run > # tmpfs /var/cache tmpfs defaults,noatime,nodiratime,mode=0755 0 0 # > meglio di no, contiene i pacchetti scaricati da apt. eventualmente, > meglio spostare la directory /var/cache/apt/archives su un disco > meccanico e sincronizzare il resto della directory /var/cache con uno > script apposito. > > 4. l'elevator deadline dovrebbe privilegiare la lettura rispetto alla > scrittura evitando freeze durante. > aggiungere in /etc/rc.local > |echo deadline > /sys/block/sda/queue/scheduler > echo 1 > /sys/block/sda/queue/iosched/fifo_batch| > verificare anche in questo caso che non siano opzioni obsolete. ripetere > le due righe per eventuali altri ssd. > > 5. avevo letto che elevator e commit per il fs di root vanno specificati > al boot. verificare se serve ancora. > aggiungere in /etc/default/grub > |GRUB_CMDLINE_LINUX="|||elevator=deadline|rootflags=commit=600| ..." > ricordarsi di eseguire update-grub subito dopo. > > da parte mia per il momento è tutto. > naturalmente, correggete i miei errori e proponete le vostre migliorie. > >
Re: disco SSD e fstab
Il 27/09/2015 23:18, Mario ha scritto: > Il 27/09/2015 21:29, girarsi_liste ha scritto: > > Posso continuare a postare qui per L'SSD oppure apro un'altra > discussione? > > > > > A me interessa se ci sono altri pareri, visto che potrebbe servire anche > ad altri in lista, attuali o futuri. > Poi credo che sia coerente con il thread e il topic, IMHO. > Sempre che per altri non lo sia! > > Mario > certo, possiamo discutere qui delle varie impostazioni e quando raggiungiamo un punto fermo (o quasi) si può aggiornare anche il wiki di debian per jessie. restando strettamente in topic possiamo elencare le opzioni utili in fstab per fs linux su ssd. 1. filesystem da usare (collegato al topic): ext4 senza journal appena creato il fs passare al terminale ed eliminare il journal con # tune2fs -O ^has_journal /dev/sd in modo da velocizzare anche il processo di installazione. ovviamente è il disco e la partizione, es. sda1 2. opzioni per fstab per il mount della partizione noatime (non scrive su disco ogni volta che si legge qualche file) nodiratime (idem per le directory) commit=600 (o comunque alto a piacere) discard (per attivare la funzione trim ove supportata) barrier=0 (solo in presenza di ups quindi portatili con batteria collegata o desktop con gruppo di continuità) nouser_xattr (evita ulteriori letture/scritture) 3. spostare in ramdisk alcune directory di sistema. controllate l'utilizzo delle varie directory per non rendere volatili dati che vi interessano. si possono sempre creare script per sincronizzare i ramdisk col fs ad avvio e chiusura ed evitare quindi perdite nel caso servisse. tmpfs /tmp tmpfs defaults,mode=1777 0 0 tmpfs /var/tmp tmpfs defaults,mode=1777 0 0 tmpfs /var/spool tmpfs defaults,mode=0755 0 0 tmpfs /var/log tmpfs defaults,mode=0755 0 0 # tmpfs /var/lock tmpfs defaults,noatime,nodiratime,mode=1777 0 0 # automaticamente in ram # tmpfs /var/run tmpfs defaults,noatime,nodiratime,mode=0755 0 0 # automaticamente in ram come link a /run # tmpfs /var/cache tmpfs defaults,noatime,nodiratime,mode=0755 0 0 # meglio di no, contiene i pacchetti scaricati da apt. eventualmente, meglio spostare la directory /var/cache/apt/archives su un disco meccanico e sincronizzare il resto della directory /var/cache con uno script apposito. 4. l'elevator deadline dovrebbe privilegiare la lettura rispetto alla scrittura evitando freeze durante. aggiungere in /etc/rc.local |echo deadline > /sys/block/sda/queue/scheduler echo 1 > /sys/block/sda/queue/iosched/fifo_batch| verificare anche in questo caso che non siano opzioni obsolete. ripetere le due righe per eventuali altri ssd. 5. avevo letto che elevator e commit per il fs di root vanno specificati al boot. verificare se serve ancora. aggiungere in /etc/default/grub |GRUB_CMDLINE_LINUX="|||elevator=deadline|rootflags=commit=600| ..." ricordarsi di eseguire update-grub subito dopo. da parte mia per il momento è tutto. naturalmente, correggete i miei errori e proponete le vostre migliorie.
Re: disco SSD e fstab
Davide Prina ha scrito il 27/09/2015 alle 10:37: > On 27/09/2015 10:06, Mario wrote: >> Il 27/09/2015 09:43, Davide Prina ha scritto: >>> On 26/09/2015 20:02, Mario wrote: >> Ero partito da qui... >> https://wiki.debian.org/SSDOptimization?action=show&redirect=SSDoptimization >> > qui infatti dice di usare noatime veramente dice: "Add the "noatime" (or "relatime") mount option in /etc/fstab, to disable (or significantly reduce) disk writes whenever a file is read. Please note that since Linux kernel 2.6.30, "relatime" is the default." che io interpreto che dal kernel 2.6.30 non è più necessario. Piviul
Re: [OT] idle3-tools, mi serve?
Il 27/09/2015 12:13, mauro altemica s.r.l. ha scritto: Il giorno 26/set/2015, alle ore 19:17, fran...@modula.net ha scritto: La cache dei dischi Sata in scrittura di solito la si tiene disabilitata e quella in lettura abilitata. la cache in scrittura puo’ essere abilitata e avere la certezza della coerenza dei dati se hai una alimentazione adeguata e garantita: i server seri, p.es., hanno una batteria tampone che tiene in vita la cache dei controller proprio per aumentare le performance e contemporaneamente avere garanzia in caso di caduta di alimentazione. Per noi poveracci, un approccio simile e’ usando un gruppo di continuita’ buonino e comunque, a meno di necessita’ effettive, e’ meglio non abusare di questa tecnologia. Mauro, se avevi seguito tutto il thread potevi vedere che quanto dici tu era già stato scritto ma il problema affrontato non è la coerenza dei dati ma capire quali eventi sul bus Sata richiedono l'intervento della meccanica dei dischi. Purtroppo per accorciare le risposte a volte è utile tagliare gli argomenti a cui non si risponde e quindi se non si leggono tutti i messaggi del thread perde un pò il filo del discorso. Luciano