Newsgroup: it.comp.os.linux.iniziare
Titolo: Spostare file di configurazioni varie su altre partizioni

Ho qualche programma  che prende parecchi gb sulla mia home(su ssd).
Ho spostato alcune di queste directory  su /var ( che è montata su un 
disco meccanico molto più grande) e rimpiazzato in home con link 
simbolici in modo da non dar fastidio ai programmi che usano quelle 
directory.
 
E' abbastanza pulita come cosa o potrei incorrere in qualche problema in 
futuro?


E` una porcata... :-)
 
Se sono programmi, puoi installarli, per tutti gli
utenti, in /usr/local/bin, oppure in /opt.
 
/var e` per i dati *variabili*.
 
bye,
 
-- 
 
piergiorgio

On 2015-11-17 17:41, Max wrote:

Piuttosto, una cosa, non hai per caso pensato ad
avere le posizioni invertite?
Cioe` /home su disco meccanico ed il resto del
sistema su SSD?
Spazio permettendo, ovviamente.
 
bye,
 
-- 
 
piergiorgio


non mi riferivo ai programmi, sono stato poco chiaro forse.
Mi riferivo ai file di configurazione nascosti che i programmi mettono 
in ".programma"
 
Alcuni di questi memorizzano una mole enorme di informazioni, non solo 
semplici file di testo. Io questi ho spostato(ad esempio le immagini dei 
device che android studio mette in .android)
 

 Spazio permettendo, ovviamente.
 
adesso il sistema è tutto su ssd tranne var e tmp:
partizione ssd 30 gb, occupati per la metà: /
partizione hdd 100 gb, occupata per un terzo: /var
tmpfs: /tmp
 
ho fatto link simbolici dalla mia home in var a cartelle tipo downloads, 
documenti e musica, oltre alle directory di configurazione suddette...
 
 
in questo modo ho su var le scritture pesanti non gravando sull'ssd.
 
 

 device che android studio mette in .android)
 
Chiaro, ma non userei /var per quello scopo.
 
bye,
 
-- 
 
piergiorgio

 in questo modo ho su var le scritture pesanti non gravando sull'ssd.
 
Mah, proprio per questo metterei /home su HDD ed
il resto su SSD.
 
bye,
 
-- 
 
piergiorgio


/var è la più adatta per quello scopo.  Lo standard FHS definisce la 
directory /var per "File Variabili come log, database, siti web, e file 
temporanei delle e-mail."  Usarla per memorizzare dati variabili degli 
utenti è IMO più che pertinente.  Molti programmi creano effettivamente 
una quantità abnorme di dati (cache, logs) che spesso creano problemi 
per i backup.  Spostare in /var quei dati che non sono necessari è 
un'ottima idea e di realizzazione semplice.
 
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   < 
http://giovanni.homelinux.net/
 >

 utenti è IMO più che pertinente.  Molti programmi creano effettivamente
 
I file di configurazione *non* sono file variabili.
 
Quello che FHS cita come esempi non credo abbia a che
fare con le configurazioni locali.
 
bye,
 
-- 
 
piergiorgio

 un'ottima idea e di realizzazione semplice.
 
Tra l'altro, in realta` e` anche complicato.
Infatti, si dovrebbe creare un folder per ogni utente.
D'altro canto, un folder per utente esiste gia` in /home,
sarebbe una duplicazione, senza un reale senso.
 
bye,
 
-- 
 
piergiorgio

 il resto su SSD.
 
in effetti si poteva fare anche cosi'. Oppure avere sia home che var  su 
hdd...
 
Chissà però che non avrei avuto una perdita di reattività nei programmi 
di tutti i giorni(Thunderbird e i browser, che hanno la cache su home 
che per sua natura è molto frammentata e beneficia dei tempi di accesso 
istantanei degli sssd...)

 istantanei degli sssd...)
 
Si, ma quei programmi caricano centinaia di MB
come codice da /usr e qualche KB come file di
configurazione da /home.
Non credo che avere la seconda su HDD faccia
molta differenza, in termini di prestazioni.
Inoltre hai altri colli di bottiglia che non
sono l'HDD.
 
Un'altra alternativa sarebbe usare cose come
"bcache" oppure "lvmcache".
 
Cioe` avere /home su HDD e una cache di /home
su SSD, assieme al resto (/usr, etc.).
 
I piccoli file caricati spesso (se quello e`
l'uso) vengono copiati in cache (SSD) e poi
funzionano sempre da quel dispositivo (la cache
e`, ovviamente, persistente).
 
Problemi:
 
1) "bcache" deve essere installato dall'inizio.
Inoltre il progetto pare un po' morente.
2) "lvmcache" si basa su "lvm", richiede quindi
che /home (o quello che e`) sia un volume "lvm".
E` un po' giovane, forse conviene aspettare, ma
avendo il vantaggio di poter essere attivato e
disattivato a piacere consente un certo margine
di test.
 
Riguardo /var, io ho il sospetto che sia soggetto
a parecchi piccoli accessi, quindi si trovi meglio
su SSD, che su HDD.
 
D'altro canto, un metodo di distribuzione dei file
tra HDD e SSD alla fine serve comunque e questo
dipende certamente dallo spazio richiesto.
Se /var ha qualche cosa come un grosso DB, allora
probabilmente un HDD e` meglio...
Questo non esclude "cache" come sopra.
 
bye,
 
-- 
 
piergiorgio

 su SSD, che su HDD.
 
può darsi, ma penso in maniera molto minore rispetto alla home...solo 
che su var si scrive una mole di dati molto più grande che alla lunga 
penso usuri di più l'ssd.
 
 
 


A parte tutte le altre discussioni se un bel gg dovessi formattare per 
reinstallare ti devi ricordare dei tuoi dati
Se fossero in /home questo problema non esiste naturalmente tenendo la 
root partition separata dalla partizione di home cosa che consiglio 
sempre su uno unix.
 
 

 un'ottima idea e di realizzazione semplice.
Però /var è modificabile da super user mentre la home è autorità dello 
user con le sotto cartelle, usare sudo per lanciare un programma che  è 
dello user o cambiare l'autorità delle cartelle, mi sembra pericoloso 
per la sicurezza. E poi se arriva un'altro user che fa il papocchio di 
log di stesso programma user differenti tutte insieme?
 
credo sia più logico creare un link ad una libreria che comunque esiste 
solo (il link) nella /home/user e dare solo a quell'utente la autorità.
 
ciao e buon linux

 dello user o cambiare l'autorità delle cartelle
 
Non c'è bisogno, e' bastato rendere l'utente proprietario di una 
cartella UTENTE_HOME sotto var e mettere tutto dentro...


su questo hai ragione, ma non mi dimenticherò :-)
 
Alla fine questa cosa l'ho solo fatta per avere una home più reattiva su ssd
 
Che poi alla fine come ti metti metti, ci sono pro e contro...ci 
vorrrebbe una partizione per ogni directory :-P

 Che poi alla fine come ti metti metti, ci sono pro e contro...
 
Cmq ricapitolando, dopo le discussioni di questo post credo che se 
dovessi fare tutto daccapo adesso farei cosi':
 
Home e VAR su hdd.
/ su ssd.
 
Cosi'è più pulito e ordinato rispetto ad ora, ma resta il piccolo 
problema di avere alcune cache frammentate su disco meccanico invece che 
su ssd, problema che adesso non c'è :-)
 

 su ssd, problema che adesso non c'è :-)
 
Ma che problema sarebbe?
 
Hai una misura corretta della differenza di prestazioni,
oppure stai solo ipotizzando?
 
Hai fatto un test, stesso PC con due configurazioni diverse?
Hai misurato la differenza in prestazioni di Firefox o
Thuderbird o quello che usi, nelle due situazioni?
 
Perche` fino a quando non hai una misura corretta e precisa
delle differenze, e` tutto speculativo e, nella migliore
delle ipotesi, non ti cambia nulla, mentre nella peggiore
hai un sistema mal configurato.
Tipo avere pezzi di /home in /var.
 
Avendo una misura precisa del carico, si puo` decidere
una strategia di utilizza del HDD e SSD.
 
bye,
 
-- 
 
piergiorgio


Puoi sempre fare una partizione su cui metti /var
Quindi puo essere staccata dalla root partition
Io comunque,come suggerito da altri,metterei l'os su ssd non  l'inverso 
ed i miei dati non li metterei in /var in quanto è una dir. di sistema e 
la lascerei solo per quello.
 
 

 Tipo avere pezzi di /home in /var.
 
Male minore potrebbe essere sfruttare, una volta tanto nella Debian, la
directory /opt ?
 
Per Nax: Se dovessi optare per opt: guarda (se non lo sai gia') che il
comando mv e' istantaneo perche' non copia nulla, cambia solo gli
indirizzi della directory o del file che sposti e ci mette 1 secondo
netto, questo pero' a patto che origine e destinazione siano sulla
medesima partizione, altrimenti copia controlla e poi cancella.
 
 
-- 
Tanti saluti
 

 directory /opt ?
 
/opt e` anche di sistema, e` un po' parallela
a /usr/local, se vogliamo.
 
/home esiste proprio perche` tutti i file utente
sono in quel posto.
Vi sono poche eccezioni, per es. /var/spool/mail/,
che, tra l'altro, si dimostra a volte un problema.
Il motivo e` che "sendmail" deve avere, in qualche
momento, i privilegi di root per poter scrivere
dentro un file utente in "mail" (poi c'e` anche
la porta 25, ma questa e` un'altra storia).
 
Proprio volendo avere un posto separato, allora
converrebbe avere un'altra partizione, chesso` in
/mnt/dati, dove si crea un secondo folder con i
permessi per l'utente e si sposta la roba dentro.
 
bye,
 
-- 
 
piergiorgio


Un'ultima cosa per curiosita' (perche' i primi tempi ce ne mettevo molte
alla Uindows, ora non lo farei mai per nessun motivo): creare una /home2
sulla root come lo giudichi come male?
 
 
-- 
Tanti saluti
 

 sulla root come lo giudichi come male?
 
La pratica che ho visto usare e` di creare un sub-folder
in /home, dove ci sono altre $HOME.
 
Cioe`, per esempio:
 
/home/utente1/
/home/utente2/
/home/colleghi/utente3/
/home/colleghi/utente4/
/home/amici/utente5/
 
Ad ogni modo, pero`, ogni utente ha sempre e solo un
unico posto dove mettere dati e, magari, programmi.
 
bye,
 
-- 
 
piergiorgio


Dimenticavo, il motivo e` che si puo` avere una /home
locale (per un utente) ed un'altra remota, via NFS per
esempio, per un altro utente.
Per motivi di ordine si possono separare in sub-folder.
 
bye,
 
-- 
 
piergiorgio

 Tipo avere pezzi di /home in /var.
 
 
Cosa che  mi comporta qualche problema grave? (che poi è il motivo di 
questo post). Penso di no, almeno da quello che è emerso da questo post.
 

 la lascerei solo per quello.
 
ma sicuramente è la cosa migliore da fare. Solo che non vedo grossi 
problemi nell'avere qualche dato(poche cose) spostato su hdd tramite 
link simbolici per alleggerire la (ssd) home (almeno in ambito 
casalingo, che è il mio caso).

 questo post). Penso di no, almeno da quello che è emerso da questo post.
 
Dipende da cosa tu consideri grave.
Da quello che ho capito, per te avere una
perdita di prestazioni trascurabile e` grave.
Quindi, usare la gerarchia del file system
in maniera non corretta sara` gravissimo.
 
Ovviamente puoi mettere i file dove vuoi, ma
non vedo il motivo di prendersi dei rischi
(tipo un upgrade che riorganizza /var) per
avere guadagni "trascurabili".
 
Siccome non si suppone che in /var vi siano file
e folder imprevisti, non vedo il motivo di
effettuare modifiche, senza un reale vantaggio.
 
Detto altrimenti, dovresti tu giudicare se ti
conviene prendere una strada "anomala" oppure
rimanere nei binari definiti.
 
Il consiglio e` di *non* usare /var, ma se
questo ti migliora la situazione in maniera
evidente, allora puo` essere fattibile.
 
Il bello di Linux e` proprio la flessibilita`,
ma senza una motivazione valida, meglio cercare
di seguire le linee guida.
 
bye,
 
-- 
 
piergiorgio

 evidente, allora puo` essere fattibile.
 
su questo siamo d'accordo :-)
 
 
 

 significa proprio "variable data".
 
Quindi, /var e` soggetta a molto piu` traffico di
/home e di conseguenza sara` molto piu` lenta.
Specie se su HDD (e magari anche su SSD, dipende
dal modello, le scritture possono essere lente).
Non e` questo il ragionamento iniziale?
 
bye,
 
-- 
 
piergiorgio

 Non e` questo il ragionamento iniziale?
 
be ma io 2 dischi ho, anche con partizioni diverse del hdd sarebbe 
uguale. Ne avessi 10 bilancerei meglio il carico ;-)
 
 

 uguale. Ne avessi 10 bilancerei meglio il carico ;-)
 
Esattamente, vedi che ci siamo.
Allora sarebbe il caso di avere /var su SSD anche e
lasciare tutta la /home su HDD.
 
Visto che /var e` soggetta a tanto traffico, vale la
pena usare il dispositivo piu` veloce... :-)
No, non mi contraddico con l'inizio del post :-)
 
bye,
 
-- 
 
piergiorgio

 pena usare il dispositivo piu` veloce... :-)
 
non sottovalutare gli aspetti "usura dell'ssd" e il fatto che l'ssd sia 
molto più piccolo del disco meccanico.
 
A me a caldo è convenuto fare in questo modo, e mi sta bene cosi' visto 
che non ci sono grosse controindicazioni.
 
Riguardo alla discussione penso che potremmo continuare per giorni senza 
cavarne un ragno dal buco, quindi meglio fermarsi :-P
 
 
 

 dei dati viene letta dal resto, non da /home.
 
La tua opinione corrisponde a quanto ho sempre letto sulle varie guide
pero` quando un paio di sere fa ho sostituito per la prima volta il mio
hard-disk del portatile con un SSD, ho deciso di partizionarlo con anche
la Home, perche` pur avendo uno scatolotto con slitta comodo per
collegare un hard-disk esterno tramite cavo USB3, non mi e` parsa la
soluzione migliore utilizzarlo ..
 
Ora l'SSD mi sembra una scheggia ma posso dirlo solo rispetto a prima
perche` non ho la possibilita` di fare paragoni con altri SSD.
 
A te come sembra? :
 
$ systemd-analyze
 
Startup finished in
2.883s (firmware) +
5.376s (loader) +
4.559s (kernel) +
6.641s (userspace) =
 
19.461s
 
# hdparm -Tt /dev/sda
/dev/sda:
Timing cached reads:   12906 MB in  2.00 seconds = 6456.32 MB/sec
Timing buffered disk reads: 1556 MB in  3.00 seconds = 518.42 MB/sec
 
Cmq prima di installare ho avuto diversi dubbi, a partire dal file
system; avrei voluto provare BTRFS ma poi ho pensato che visto che usavo
una Debian Testing con lo scopo di testarla forse era meglio se rimanevo
sull'ext4 che e` lo standard.
 
Ho preso anche spunto da questa guida un po' datata:
 
https://www.namhuy.net/1563/how-to-tweak-and-optimize-ssd-for-ubuntu-linux-mint.html
 
 
pero` gia` la sez. "Adding noatime and nodiratime" mi ha lasciato dei
dubbi perche` mi pareva di ricordare che 'nodiratime' non vada molto
bene e cosi` non l'ho messo.
 
Per quanto riguarda 'Tmpfs' ho pensato di non modificare il file 'fstab'
ma lasciar fare a systemd.
 
<cite>
Why is this mount established via a systemd unit file, instead of an
entry in /etc/fstab?
 
We believe that /etc/fstab is the place to configure real file systems,
for actual user data, backed by real devices. The API file system /tmp
does not qualify for that in our eyes. /tmp is very much something that
should just exist as part of the OS and needs no user configuration. It
is our goal to allow systems to boot up fully functional with an
(almost) empty /etc/fstab. Also it is much easier to enable this logic
for existing installs without the need to patch /etc/fstab.
</cite>
http://fedoraproject.org/wiki/Features/tmp-on-tmpfs#Comments_and_Discussion
 
 
Anche per il trim lascio fare a systemd; ho seguito questa guida:
https://mjanja.ch/2013/04/systemd-service-to-trim-free-ssd-cells-at-boot/
 
 
Ho letto di altre possibili accorgimenti, ad esempio per la cache dei
browser ma non ho ancora pravato e sono intervenuto solo sul file
/proc/sys/vm/swappiness
 
 
 
 
 
 
 
 
 

 /proc/sys/vm/swappiness
 
Cosa hai messo in /proc/sys/vm/swappiness?
E come? C'e` un "sysctl" probabilmente...
Non ho mai considerato una modifica a quel livello.
 
bye,
 
-- 
 
piergiorgio

 Non ho mai considerato una modifica a quel livello.
 
Ho solo seguito la guida citata prima:
https://www.namhuy.net/1563/how-to-tweak-and-optimize-ssd-for-ubuntu-linux-mint.html
 
 
------------------------------------
To check your swappiness setting on your system, you should see the
value of 60 as default.
$ cat /proc/sys/vm/swappiness
The value is up to you to decide. Here is my suggestion
 
2 GB = 30
4 GB = 10
6 GB or more = 0
 
To change swappiness setting:
$ su -
# nano /etc/sysctl.conf
And add this line into sysctl.conf file.
vm.swappiness = 10
------------------------------------
 
Io avendo 4 GB di RAM ho messo "10" , pero` da altra parti ho letto che
sarebbe il caso di mettere "1" e non "0" se si dispone di 8 GB.
 
C'era indicata li` anche una modifica al "dirty_background_ratio" e al
"vm.dirty_ratio" ma non ho capito esattamente cosa siano per cui mi sono
astenuto dal fare una modifica che non comprendo.
 
Per quanto riguarda la cache del browser le indicazioni sempre li`
riportate non corrispondono per nulla sul mio sistema.
 

 
https://www.namhuy.net/1563/how-to-tweak-and-optimize-ssd-for-ubuntu-linux-mint.html
 
 
OK, thanks!
 
bye,
 
-- 
 
piergiorgio

 E quindi /tmp in root...
 
Quali sono i pro ad avere /tmp in una partizione separata tutta sua e
non in root?
 
 
-- 
Tanti saluti
 

 non in root?
 
Dipende dall'uso del sistema.
 
Per es., vi sono programmi di elaborazione video
che creano enormi file in /tmp.
In questo caso sarebbe meglio avere /tmp su una
partizione separata, magari anche un HDD separato.
Ma anche un CD burner front-end crea file immagine
in /tmp, che, gia` per un DVD, possono essere
diversi GB.
 
In generale, tmpfs e` una buona scelta, nel caso
solo programmi "standard" usino /tmp, quindi con
pochi, piccoli file.
 
D'altro canto, potrebbe essere che uno non voglia
usare RAM per /tmp e non voglia neanche separare
il tutto da root, per motivi di semplicita`.
 
bye,
 
-- 
 
piergiorgio

 penso usuri di più l'ssd.
 
se cerchi su google c'e' chi ha fatto i calcoli precisi , ma a scriverci una 20GB al giorno su SSD, cominci ad avere problemi di usura (aka celle che non riesci piu' a scrivere) tra una 15ina di anni.
 
IMHO, inutile sbattersi.
 
Poi dipende da quanto valuti valga il tuo tempo: se valuti che quelle 2,3,4 ore che investi a spostare roba tra SSD e HD, fare link ecc. valgano meno dei 100 euro che ti costa un SSD nuovo...beh sta a te decidere.
 
Se invece lo fai perche' per te e' un hobby, allora fai finta che non abbia detto niente.
 
Ciao Jack