[Risolto] Fstab non prende la modifica della tmp su ram

[texdb]

Ciao a tutti......
Ho un problema a seguito dell'instrallazione di un disco SSD,
Ho eliminato il journaling dal file system....con esito positivo.
ora sto cercando disperatamente di eliminare la scrittura dei file temporanei su disco,  trasferendo tutti i file temporanei su ram

ho letto diverse guide, e tutte indicano un unica procedura, che è quella di inserire le seguenti righe sul file fstab

#            
proc            /proc           proc    nodev,noexec,nosuid 0       0
# / was on /dev/sdb1 during installation
UUID=72c37ea6-4f74-482a-a6a8-e650bac19082 /               ext4    noatime,discard,errors=remount-ro 0       1
# /Test_OS was on /dev/sdb3 during installation
UUID=cc880239-0346-461a-a6a2-6a8307979d29 /Test_OS        ext4    defaults        0       2
# /home was on /dev/sdb2 during installation
UUID=42bc5846-da14-4825-acc1-e61e00adf690 /home           ext4    defaults        0       2
# temp e log su RAM
tmpfs /tmp tmpfs defaults,noatime 0 0
tmpfs /var/tmp tmpfs defaults,noatime 0 0
tmpfs /var/log tmpfs defaults,noatime 0 0
#monta in automatico disco da 1Tb all'avvio
/dev/sda1    /media/Dati  rw,ext4 defaults  0    0

il risultato è che comunque, mi scrive i file su disco SSD (sdb1)...

uso UBUNTU 12.04 e ho 4Gb di RAM

cosa sbaglio?

[steff]

Prova le righe

Codice: Seleziona tutto

 none                   /var/log      tmpfs     size=20M   0      0
 none                   /tmp          tmpfs     size=500M  0      0
 none                   /var/tmp      tmpfs     size=50M   0      0

[texdb]

Ho aggiunto le righe all fstab come da te indicato....ma non cambia nulla

[steff]

Come controlli dove scrive? Hai riavviato?

[texdb]

Dopo la modifica ho cancellato tutta la cartella tmp. Poi ho riavviato la sessione....ho verificato la tmp- e ci ho trovato altri file salvati.

[steff]

La /tmp ecc esiste ovviamente, non è che non esiste. Ma controlla la data dei file in /var/log

[texdb]

La /tmp ecc esiste ovviamente, non è che non esiste. Ma controlla la data dei file in /var/log

data... 19 marzo ore 22.47 ....orario seguente al io riavvio....
è per quello che dico che non sembra funzionare.

e comunque, con la stessa procedura...su onereic 11.10, la tmp era vuota....non ci trovavo mai alcun file

[steff]

La /tmp è vuota se la guardi dal cd live, ma qualche file ci dovrebbere essere normalmente.

orario seguente al io riavvio

??

[texdb]

La /tmp è vuota se la guardi dal cd live, ma qualche file ci dovrebbere essere normalmente.

orario seguente al io riavvio

??

La mia richiesta...nasce dal fatto di preservare il disco SSD da "inutili" scritture.... ecco il motivo per cui vorrei non scrivere proprio niente sul disco.
A me non interessa tenere la tmp in ordine, o limitare la scrittura...io vorrei proprio eliminare qualsiasi tipo di scrittura.....tutto qui.

é possibile farlo? e se si, come?
Parto anche dal presupposto, che con i medesimi comandi, su ubuntu 11.10, la tmp era completamente vuota.

La mia frase del post precedente era scritta male.....intendevo....orario seguente al MIO riavvio.

[steff]

La /tmp viene usata, non mi torna il discorso di una /tmp vuota sempre. Se adesso la vedi non vuol dire che NON è in ram.

Posta

Codice: Seleziona tutto

mount

I file presenti in /var/log dovrebbero essere sempre avere la  data del avvio, non antecedente.

[texdb]

La /tmp viene usata, non mi torna il discorso di una /tmp vuota sempre. Se adesso la vedi non vuol dire che NON è in ram.

Posta

Codice: Seleziona tutto

mount

I file presenti in /var/log dovrebbero essere sempre avere la  data del avvio, non antecedente.

Ah...quindi mi stai dicendo...che se anche vedo molti file sulla tmp, in realtà non sono scritti su disco ma solo su ram?
oppure mi stai dicendo che non esiste nessun modo per tenerla vuota al 100%?

Si, ho verificato, i file su /var/log hanno la data di avvio.

[el_Felix]

So che non ti sarò di grande aiuto, comunque potresti prendere in considerazione l'idea di usare un disco magari vecchio o dei dischi esterni usb molto piccoli (da 30-40 Gb) che potresti usare apposta per i filesystem temporanei e di log.

[texdb]

So che non ti sarò di grande aiuto, comunque potresti prendere in considerazione l'idea di usare un disco magari vecchio o dei dischi esterni usb molto piccoli (da 30-40 Gb) che potresti usare apposta per i filesystem temporanei e di log.

potrebbe anche essere un idea....dato che ho un disco da 1Tb di tipo tradizionale che uso come disco Dati Personali.

Ma come potrei fare  per indirizzare i file tmp su quel disco?

[Wilson]

Ah...quindi mi stai dicendo...che se anche vedo molti file sulla tmp, in realtà non sono scritti su disco ma solo su ram?
oppure mi stai dicendo che non esiste nessun modo per tenerla vuota al 100%?

Beh, mi paiono due ovvietà.
Se i programmi per funzionare hanno bisogno di scrivere files temporanei è ovvio che quando li avvii la cartella si popoli di questi files.
Invece la prima frase descrive esattamente quello che volevi fare: fare in modo che i files scritti in /tmp non siano scritti nella partizione montata come /, ma su un altra (nel tuo caso un ramdisk).

ps: per quel che ne so solo gli SSD più vecchi hanno un vero problema di numero di scritture (nel senso che la durata media in condizioni di carico medio-alto per uso domestico è stata stimata in più di 10 anni, se non ricordo male), valuta se sia davvero il caso di rimuovere il journaling (anche il leggero miglioramento di velocità non dovrebbe compensare i potenziali problemi).

[Wilson]

edit: ricordavo male, a quanto pare già dal 2007 la durata stimata senza particolari precauzioni era di 51 anni (e da allora le cose sono migliorate parecchio), pare che la leggenda di un problema di numero di scritture degli SSD sia dovuta a una politica commerciale per evitarne l'adozione sui server (che avrebbero avuto grandi incrementi di prestazioni a bassissimo costo).
http://www.storagesearch.com/ssdmyths-endurance.html

[texdb]

Ah...quindi mi stai dicendo...che se anche vedo molti file sulla tmp, in realtà non sono scritti su disco ma solo su ram?
oppure mi stai dicendo che non esiste nessun modo per tenerla vuota al 100%?

Beh, mi paiono due ovvietà.
Se i programmi per funzionare hanno bisogno di scrivere files temporanei è ovvio che quando li avvii la cartella si popoli di questi files.
Invece la prima frase descrive esattamente quello che volevi fare: fare in modo che i files scritti in /tmp non siano scritti nella partizione montata come /, ma su un altra (nel tuo caso un ramdisk).

ps: per quel che ne so solo gli SSD più vecchi hanno un vero problema di numero di scritture (nel senso che la durata media in condizioni di carico medio-alto per uso domestico è stata stimata in più di 10 anni, se non ricordo male), valuta se sia davvero il caso di rimuovere il journaling (anche il leggero miglioramento di velocità non dovrebbe compensare i potenziali problemi).

Quindi , non solo mi consiglieresti di lasciare i file tmp di default, ma addirittura rimettere in funzione il journaling, fregandomene altamente delle scritture su disco (il mio è un OCZ Agility 3 da 60 GB), tanto quelli moderni per un uso normale durano almeno 10 anni senza problemi?

Beh...detta così, sembrerebbe molto facile.....e addirittura, sembrerebbe dar torto anche a un certo articolo che ho letto qui
http://www.uielinux.org/guide-e-tutoria ... i-ssd.html#

Io onestamente sono combattuto, anche per mia ovvia ignoranza in materia.....

Quale sarebbe quindi la soluzione migliore ?(tenendo conto che tra 10 anni il mio disco sarà già bello che superato....)

[Wilson]

Onestamente non mi sento di consigliare nulla, visto che non sono un progettista di hardware e non ho idea di quali siano le reali possibilità del tuo disco: non voglio assolutamente prendermi responsabilità in quel senso.

Al massimo ti posso dire che per il mio, dopo aver girato per siti vari per qualche ora (in pratica ci ho passato una domenica intera), ho deciso di non fare assolutamente nulla, anzi, lo uso pure per la swap (o almeno lo usavo, sono in attesa di un nuovo pc con molta più RAM e conto di non averne più bisogno).

Se hai molta RAM e non la saturi mai può essere una bella soluzione fare (come hai già fatto, se ho capito) un ramdisk da montare in /tmp, così sei sicuro che si cancelli a ogni riavvio e potresti avere un incremento di prestazioni in alcuni programmi (comunque marginale, credo).

Invece il journal è utile, evita di perdere dati (e a volte di dover reinstallare da capo) se una copia non va a buon fine (ad esempio perché manca la luce o per un crash del pc per un bug), e non credo che l'incremento di prestazioni dovuto alla minore attività sul disco sia così utile, soprattutto su un disco con le prestazioni di un SSD.
Quindi non è detto che, se anche ci fosse davvero un limite alle scritture raggiungibile in pochi anni, il guadagno valga il costo.

[texdb]

Onestamente non mi sento di consigliare nulla, visto che non sono un progettista di hardware e non ho idea di quali siano le reali possibilità del tuo disco: non voglio assolutamente prendermi responsabilità in quel senso.

Al massimo ti posso dire che per il mio, dopo aver girato per siti vari per qualche ora (in pratica ci ho passato una domenica intera), ho deciso di non fare assolutamente nulla, anzi, lo uso pure per la swap (o almeno lo usavo, sono in attesa di un nuovo pc con molta più RAM e conto di non averne più bisogno).

Se hai molta RAM e non la saturi mai può essere una bella soluzione fare (come hai già fatto, se ho capito) un ramdisk da montare in /tmp, così sei sicuro che si cancelli a ogni riavvio e potresti avere un incremento di prestazioni in alcuni programmi (comunque marginale, credo).

Invece il journal è utile, evita di perdere dati (e a volte di dover reinstallare da capo) se una copia non va a buon fine (ad esempio perché manca la luce o per un crash del pc per un bug), e non credo che l'incremento di prestazioni dovuto alla minore attività sul disco sia così utile, soprattutto su un disco con le prestazioni di un SSD.
Quindi non è detto che, se anche ci fosse davvero un limite alle scritture raggiungibile in pochi anni, il guadagno valga il costo.

Ho 4Gb di RAM e non la saturo mai.....anzi, è fin troppa.

Ti rongrazio delle informazioni, quella del journaling pensavo fosse una cosa che si potesse fare senza grossi problemi, ma a sto punto, credo che opterò per ripristinare tutto come se fosse un disco tradizionale.

Esistono delle avviasaglie per quanto riguarda un disco SSD che si sta per guastare...o che funziona male?
Giusto per capire....se....ti abbandona di botto o se prima in qualche modo da dei segni di cedimento...

[Wilson]

Ho 4Gb di RAM e non la saturo mai.....anzi, è fin troppa.

Ti rongrazio delle informazioni, quella del journaling pensavo fosse una cosa che si potesse fare senza grossi problemi, ma a sto punto, credo che opterò per ripristinare tutto come se fosse un disco tradizionale.

Esistono delle avviasaglie per quanto riguarda un disco SSD che si sta per guastare...o che funziona male?
Giusto per capire....se....ti abbandona di botto o se prima in qualche modo da dei segni di cedimento...

Purtroppo non ho tempo per controllare e, ma da quel che ricordo più che mollarti si restringe (nel senso che alcuni settori diventano "sola lettura" e il disco comincia a dichiarare meno spazio disponibile di prima), ma i controller "moderni" hanno dei sistemi per distribuire le scritture sui diversi settori ed evitare questo effetto.

ps: il journal a qualcosa serve, altrimenti non sarebbe presente in tutti i FS moderni, però in generale ti consiglierei di informarti sui vari pro e contro e poi scegliere sulla base delle tue specifiche preferenze (non è detto che ciò che va bene per me vada bene anche a te).
Per il resto non vedo un motivo per ripristinare la /tmp, puoi anche lasciarla così, se poi avrai problemi di RAM puoi sempre tornare indietro.

[steff]

Vorrei vedere ancora

Codice: Seleziona tutto

mount

Ormai l'hai fatto, un ulteriore trucco è di usare la ram per il cache dei browser, con l'effetto collaterale che diventano pure più veloci.

http://www.linuxreaders.com/2011/01/11/ ... ra-ubuntu/