Newsgroup: it.comp.os.linux.sys
Titolo: Swap su SSD

AFAIK il kernel utilizza la RAM anche come cache per le letture dei dati da disco.
Pertanto, se leggo 100MB da disco ed ho ram a disposizione, le letture successive saranno effettuate dalla ram anzichè dal disco.
 
Se tanto mi da tanto, mettere la swap su SSD dovrebbe consentire di utilizzare enormi quantitativi di RAM+storage performanti come una sorta di grossa cache disco.
Supponendo di avere un SSD da 200gb (non so la misura esatta), posso fare un partizione di swap da 100GB che sarà usata, in caso di necessità, anche come cache.
 
C'è modo di istruire il kernel ad usare tale partizione *solo* per la cache disco anzichè come swap tradizionale in cui ci va a finire un dump di qualunque cosa ci sia in RAM? Non mi interessa swappare su SSD tutta la ram, voglio usarla solo come cache per i dischi.

C'è modo di istruire il kernel ad usare tale partizione *solo* per la cache disco
 
No. L'SSD e' visto come block device, quindi gia' avresti problemi a non
fargli fare caching dell'SSD.
 
Di conseguenza "non si puo' fare".
 
Che comunque in informatichese significa "bisogna usare un trucco" :-D
 
Il trucco e' una patch del kernel chiamata bcache, nata per l'appunto in
modo da sfruttare i punti forti dei SSD. 
http://lwn.net/Articles/394672/
 
 
Leonardo
 
-- 
What would'st thou do, my squire so gay, that rides beside my reine
Were ye Glenallan's Earl this tide, and I were Roland Cheyne?
To turn the rein were sin and shame, to fight were wondrous peril:
What would ye do now, Roland Cheyne, were ye Glenallan's Earl?

 letture successive ...
 
Non capisco l'utilità di tutto queste jacovelle. 
Non capisco perché vuoi implementare questa sorta di cache a due
livelli (tra l'altro tra cache interna al disco, DMA e varie mrchingegni
della scheda madre già le cache del disco sono a più livelli) 
Già di per se il kernel usa la RAM che avanza in buffer e cache; se
vuoi aumentare la cache del IMHO la cosa più semplice è installare 
altra RAM.
 

 altra RAM.
 
256G di ram costano un pelino di più di un SSD. (e comunque il server attuale non li supporta)
Ho un fileserver con materiale piuttosto corposo che quando viene letto la prima volta (ad esempio alla mattina) richiede parecchio tempo, tutti gli accessi successivi invece sono fulminei. Questo indica che il primo accesso avviene da disco, i successivi da RAM.
 
Il problema è che questi file non ci stanno tutti in ram, quindi, di tanto in tanto, alcuni file (quelli usati più di frequente) restano 'veloci' altri rallentano perchè rimossi dalla ram.
 
Con un SSD dovrei risolvere. Dovrebbe bastare anche mettere lo swap su ssd, il resto era solo per una questione di ottimizzazione.

 Con un SSD dovrei risolvere.
 
Secondo me anche. Ma come dispositivi di storage del file server, non come 
sostituti della cache. Se poi vuoi un sistema del genere, forse sarebbe piu` 
opportuno implementare un sistema che analizzi i file piu` utilizzati e li 
copi su di una SSD, proponendo all'utente questi ultimi piuttosto che quelli 
sullo storage tradizionale (Python + FUSE sono a tua disposizione, sempre se 
non esiste qualcosa di gpa` pronto)
 
Enrico

 non esiste qualcosa di gpa` pronto)
 
http://sourceforge.net/projects/ohsm/
 
 
Ma non l'ho provato.
 
-- 
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

 non esiste qualcosa di gpa` pronto)
 
I file son sempre i soliti.
Però, dal punto di vista prettamente pratico, è più semplice far swappare su SSD che mettersi a fare script di analisi dei file.
 
Pensavo ci fosse un qualche flag per il mount della swap che mi permettessi di decidere cosa swappare, in mancanza di tale possibilità, faccio swappare tutto e sono a posto, senza impazzire.

 faccio swappare tutto e sono a posto, senza impazzire.
 
Occhio che la soluzione tua sembra peggiore del male.
 


Credo che sia un pò esagerato affermare ciofeca lo sticky bit
Occorre sempre valutare il contesto in cui nacque.
Quando nacque (parliamo degli anni 70) i kernel e l' hw  non  erano 
quelli di oggi
Non  esisteva il DMA tanto per dirne una
Ovvio che con il migliorare delle tecnologie di scheduling, la gestione 
dello swap, il DMA, e la cache interna lo sticky è caduto in disuso 
(oggi viene ancora usato ma ha un' altra funzione)
 

 ...
 
 
In realtà lo sticky bit sui file eseguibili non faceva eliminare il
programma dalla RAM una volta terminato il programma. Effetivamente
questo dava moltissimi vantaggi in un mondo dove la memoria paginata
non era molto diffusa, dove la memoria segmentata era più diffusa e
il DMA era sperimentale. Ma il problema principale era dove e a quali
file applicare lo sticky bit. È ovvio che una adeguata statistica e  
permette di sapere a quali file è opportuno mettere lo sticky bit e a
quali no, ed è altrettanto ovvio che se metti lo sticky bit a tutti i
programmi ottieni solo un blocco del sistema (mmm DoS ante litteram?)
Ma il problema principale è dare privilegi a programmi; una volta
caricato un programma in memoria non c'era verso di toglierlo, con
qualsiasi scheduler moderno o antico e questo in un mondo dove 
l'hardware non era quello di oggi e la memoria era molto costosa
lo sticky bit faceva girare le palle a molti amministratori.
Se poi metti che per applicare una patch di sicurezza o modificare un
programma in esecuzione dovevi camminare sui carboni ardenti, saltare
nel cerchio di fuoco e superare cavalli di Frisia...
 
D'accordo, oggi le directory usano lo sticky bit per fare tutt'altro 
(e in modo non molto efficiente) ma non è una continuazione dello
sticky bit perché rimane solo il nome.
 
E certamente lo sticky bit versione Solaris non è lo sticky bit 
classico, anzi è proprio l'opposto: se un file regolare non eseguibile
ha lo sticky bit impostato, il kernel lo tratta come un file di swap
e non lo mette in una cache. Il comportamento è proprio l'opposto:
 - non può venire applicato ai programmi ma solo ai file dati
 - non carica i programmi in RAM ma anzi impedisce che vengano 
    caricati 
 - non sovraccarica la RAM ma la libera
 
Riassumendo: il comportamento classico dello sticky bit mi sembra 
problematico anche su macchine moderne mentre il comportamento secondo
Solaris mi sembra più razionale ed ordinato.
 
 

 senza impazzire.
 
Mi trovo d'accordo con mallin.shetland
 
Enrico


Su Linux non è mai stato usato e implementato per quanto ne so
D'altronte Linux è un kernel relativamente recente.
 
Nei sistemi *BSD era presente nelle vecchie versioni; a oggi è eliminato
eccezion fatta per NetBSD (1)
 
 
(1) fonte wikipedia
 
 
 
 
 

 Mi trovo d'accordo con mallin.shetland
 
 
Forse mi sono espresso male.
con "swappare tutto" intendevo dire: "creo una partizione di swap su ssd e faccio gestire il tutto al kernel, come di consueto" e non "forzo lo swap in qualche strano modo"
 
Lui swappa se ne ha bisogno, sapendo che lo swap anzichè stare su un disco SATA sta su un SSD. In questo non c'è nulla di negativo/esoterico se non un intrinseco aumento di performance.

 in qualche strano modo"
 
Si, questo era chiaro, rimango pero` perplesso che possa servire a qualcosa 
proprio perche` e` il kernel a decidere se utilizzarla o meno. Nel 
frattempo, mentre zuzzurellavo su IRC mi e` stato suggerito questo, che 
potrebbe essere proprio quello che cerchi: 
http://www.jukie.net/bart/blog/20090612215638
 
 
Enrico

 
http://www.jukie.net/bart/blog/20090612215638
 
 
Vado a leggere
 

 faccio swappare tutto e sono a posto, senza impazzire.
 
Per quanto ne so io, nella swap non finiscono buffer e cache, ma solo 
aree di memoria allocate dalle applicazioni.
 
La cosa più semplice e veloce è mettere una SSD e copiarci dentro i file 
che ti servono veloci (ed eventualmente montarla in una cartella tra 
quelle condivise in rete, istruendo gli utenti su cosa mettere lí).
 
In questo modo sono in RAM finché ce ne stanno, e quando non ci stanno 
vengono caricati dalla SSD.
 
Bye.

 vengono caricati dalla SSD.
 
Era ciò che volevo evitare, ma credo non ci siano altre soluzioni.
Sai bene che è impossibile istruire la gente, se vedono che il disco X è più performante di Y, ci mettono sopra anche il filmato del matrimonio o le foto delle ferie estive.

 le foto delle ferie estive.
 
D'altro canto sai chi ha messo i file lì e hai più controllo su cosa 
viene mantenuto "ad alta velocità" e cosa no, mentre nel caso venga 
lasciato tutto al sistema, appena uno scarica il suo filmato del 
matrimonio toglie dai buffer tutti i file che c'erano, rallentando tutti.
 
Bye.
 

 matrimonio toglie dai buffer tutti i file che c'erano, rallentando tutti.
 
Si, anche questo è vero.

 Cosa non hai capito?
 
Dal tuo primo messaggio avevo capito che volevi usare la swap su SSD 
presupponendo che venisse usata anche come buffer e cache.
 
E visto che nel messaggio a cui ho risposto dicevi appunto il contrario, 
non capivo cosa volevi fare. :)
 
Bye.

 non capivo cosa volevi fare. :)
 
...ripensandoci, non avrebbe alcun senso per il motivo che sia io che te stiamo dicendo.