Poiche' avrei bisogno di piu' disco dam di questa fisicamente
installata, avevo pensato di formattare /dev/shm con un file system che
preveda la compressione "al volo" dei dati, per permettere di guadagnare
spazio.
Quindi la doanda e': come e' formattata la /dev/shm? In ext2? E'
possibile imporre, che so, smashfs? E se e' possibile, dove occorre
"mettere le mani" per eseguire le modifiche del caso?
PS: inutile dire che NON posso espandere ulteriormente la memoria fisica
ne' aumentare ulteriormente la parte di ram dedicata a /dev/shm
--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-ital...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listm...@lists.debian.org
To UNSUBSCRIBE, email to debian-ital...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
> Poiche' avrei bisogno di piu' disco dam di questa fisicamente
> installata, avevo pensato di formattare /dev/shm con un file system che
> preveda la compressione "al volo" dei dati, per permettere di guadagnare
> spazio.
Ad esempio? smashfs, che citi, non lo conosco, mentre squashfs e` READ
ONLY...
> Quindi la doanda e': come e' formattata la /dev/shm? In ext2? E'
> possibile imporre, che so, smashfs? E se e' possibile, dove occorre
> "mettere le mani" per eseguire le modifiche del caso?
Non e` ext2, e` tmpfs, e dubito possa essere modificato, perche' il device
e il filesystem in questo caso son tutt'uno. Eventualmente puoi creare un
file _dentro_ il tuo disco ram e quindi formattare questo montato in
"loop" con il filesystem che ti pare, puoi anche crearlo come file sparso,
in modo che ti occupi memoria man mano che si riempie... Svantaggio, non
puoi invece sperare che si liberi memoria quando rimuovi file.
> PS: inutile dire che NON posso espandere ulteriormente la memoria fisica
> ne' aumentare ulteriormente la parte di ram dedicata a /dev/shm
Puo' sembrarti una scemata, ma in realt� non lo e` e puo' anche venir
comodo in alcuni casi... la memoria usata da tmpfs puo' essere "swap-ata",
ovvero il disco in RAM dovrebbe poter effettivamente essere piu' grande
della memoria fisica, quindi il disco vero verra` usato se, quando, e
quanto serve per compensare un uso intensivo del disco in memoria. Potrei
ricordare male, ma mi sembra proprio che questo fosse uno dei vantaggi di
tmpfs rispetto al piu' datato ramfs.
Saluti!
Marco
>Puo' sembrarti una scemata, ma in realtà non lo e` e puo' anche venir comodo in alcuni casi...
>la memoria usata da tmpfs puo' essere "swap-ata", ovvero il disco in RAM dovrebbe poter effettivamente
>essere piu' grande della memoria fisica, quindi il disco vero verra` usato se, quando, e quanto serve per
>compensare un uso intensivo del disco in memoria. Potrei ricordare male, ma mi sembra proprio che questo
>fosse uno dei vantaggi di tmpfs rispetto al piu' datato ramfs.
Se ho (esempio) iG di ram puntata da /dev/shm e ci scrivo dentro, alla fine non ottengo un errore di "disk full"? Cheido perche non ho sottomano un pc linux con cui provare.
Te lo risconsiglio, perche' i file cancellati _NON_ libereranno memoria.
E ti chiedo anche nuovamente, che FS vuoi metterci?
> Se ho (esempio) iG di ram puntata da /dev/shm e ci scrivo dentro, alla
> fine non ottengo un errore di "disk full"? Cheido perche non ho sottomano
> un pc linux con cui provare.
Certo, se decidi che la dimensione e` "size=1G", una volta riempito il
giga, di da` errore, ma basta un "mount -o remount,size=2G" per
allargarlo, e basta aggiungere un po' di swap per continuare a farlo
stare. Anche perche` un disco in ram con "size=2G" occupa effettivamente
due giga _solo_quando_e`_pieno_ e riduce l'uso di ram appena cancelli.
Insomma, a meno che nello scenario che hai a disposizione il disco rigido
sia praticamente inesistente, ti consiglio nuovamente di mettere un po' di
swap e allargare il disco in ram.
Poi ci dirai quale soluzione ha funzionato meglio.
Ciau,
--
http://bodrato.it/software/