Newsgroup: it.comp.os.linux.sys
Titolo: lvmcache

Qualcuno lo ha usato in produzione?
Piuttosto che fare un server full-ssd, che mi preoccupa alquanto, sarei tentato a fare un più tradizionale RAID-6 SAS, e magari 2 dischi SSD in RAID1 da usare come cache tramite lvmcache.
 
Domandine:
1) in caso di writetrough, le performance, sono comunque migliorative anche se i dati devono essere scritti simultaneamente su disco meccanico?
 
2) il RAID-1 gestito da LVM, come si comporta? Meglio evitare strani accrocchi ed usare un più standard raid md anche per la cache, o è conveniente (perchè?) crearla in RAID-1 direttamente con LVM?
 
3) cosa succede se il volume di cache dovesse morire di botto? Si pianta l'intero sistema? Funziona uguale in maniera trasparente ma perdo i dati non ancora scritti sul disco meccanico?
 
Suggerimenti ?
L'usare una cache SSD in RAID-1 ha i suoi vantaggi: a parte la protezione (parziale, per i motivi scritti in altro thread causati dal RAID-1 su SSD) in caso di guasto ad un disco, le performance in scrittura sarebbero comunque di qualche ordine di grandezza superiori a quelle standard su disco meccanico (nonostante la doppia copia da dover scrivere), ma quelle in lettura raddoppiano.
Quindi avrei il doppio di performance di lettura di un SSD e comunque i vantaggi in scrittura.
 
Sapete se è possibile impostare la frequenza di scrittura su disco in caso di writetrough? Poter impostare ad esempio 5-10 minuti di scritture in background, in caso di problematiche, mi farebbe perdere al massimo 5-10 minuti di dati.
E' palese che su questo sistema non metterei mai la /var/lib/mysql ma certamente tutte le directory con i siti dei clienti si. al 90% sono letture.

 E' palese che su questo sistema non metterei mai la /var/lib/mysql ma certamente tutte le directory con i siti dei clienti si. al 90% sono letture.
 
Confondi write-tru :-) con write-back?
 
Ad ogni modo, lvmcache e` un "hot spot cache",
cioe` un certo blocco deve essere letto piu`
volte, prima di essere promosso nella cache.
 
Dai miei test funziona, se si legge sempre
continuamente lo stesso file.
 
Se l'uso del disco rotante :-) e` sparso,
non serve a nulla.
In questo caso meglio bcache (che pero` ha
altri svantaggi).
 
BTW, esiste anche dm-writecache (credo si
chiami), specifico per le scritture...
 
bye,
 
-- 
 
piergiorgio

 volte, prima di essere promosso nella cache.
 
Nel mio caso, potrebbe funzionare.
A parte il fatto che si può impostare la sensibilità al "letto più volte", in caso di webserver con hosting condivisi, i file letti sono al 90% sempre gli stessi.


In questo caso, direi che e` una buona soluzione.
Non fidarti della soglia di "promotion", leggevo
diversi commenti, uhm, "sorpresi" su come e quanto
funzioni quel parametro.
 
Il grosso vantaggio, IMHO, di lvmcache e` che si
puo` attivare / disattivare su volumi LVM al volo.
 
Quindi, si puo` configurare il sistema con LVM e,
poi, in un secondo tempo, aggiungere la cache.
 
Non so quanto sia "production ready", pero`, devi
vedere cosa dica esattamente la documentazione.
 
Ti conviene, come al solito, fare delle prove.
 
bye,
 
-- 
 
piergiorgio

 Ti conviene, come al solito, fare delle prove.
 
Una idea malsana l'avrei: mettere in cache tutto il LV dei domU di XenServer

 Qualcuno lo ha usato in produzione?
 
È dopo aver visto come funzionano sia lui che gli snapshot che ho deciso che
LVM è una merda. Se ho bisogno di queste cose, vado di ZFS e vivo felice
 
Enrico
P.S. sì, lo so, sto cominciando ad essere monotono...

 LVM è una merda. Se ho bisogno di queste cose, vado di ZFS e vivo felice
 
Dai, spiega bene.


Per gli snapshot LVM:
 
 - Eseguo il comando;
 - Viene rinominato e nascosto il volume (suffisso -real) su cui sto creando lo
   snapshot;
 - Viene creato un volume (suffisso -cow) su cui verranno copiati i dati
   originali e modificati;
 - Viene creato un volume (suffisso -snap) su cui l'utente potrà interagire per
   leggere i dati;
 - Viene creato un volume sostitutivo su cui l'utente potrà interagire.
 
Viene da sé che è una gestione allucinante e poco efficiente, al punto che
l'uso degli snapshot LVM è consigliato per attività spot. Per fare un paragone,
uno snapshot su Btrfs o su ZFS è più simile a una etichetta sullo stato del
disco in un determinato momento ovvero tutti i dati successivi allo snapshot
non vanno a sovrascrivere quelli vecchi perché hanno una data differente (non
mi viene da spiegarlo meglio).
Per quanto riguarda lvmcache, sinceramente mi sono fermato alla guida che dice
pressappoco di:
 
 - Aggiungi il disco dedicato alla cache al VG;
 - Crea un LV dedicato alla cache dei dati;
 - Crea un LV dedicato alla cache dei metadati;
 - Crea un pool con i due LV creati in precedenza;
 - Aggancia il pool al LV dedicato ai dati.
 
Ora, tutto questo giro mi sembra un porcaio che mi fa venire solo dei dubbi sul
funzionamento del sistema. Per capirci, posto che non vedo il senso di fare a
mano operazioni che dovrebbero essere fatte in automatico (io dovrei vedere
solo il cache pool, e non dovrei fare a mano gli altri LV), cosa succede se il
disco dedicato alla cache si rompe? Da questo punto di vista ZFS è più sicuro:
 
 - Il disco (o la partizione) lo agganci con un semplice
   zpool add pool cache disco;
 - Il disco non fa parte del pool ma viene marchiato come cache;
 - Se voglio posso fare un mirror della cache, anche se non serve;
 - Se si rompe il disco contenente la cache, l'unico impatto che avrò sul
   sistema è che andrà più piano.
 
A questo punto, viste tutte le considerazioni che ho fatto prima, mi viene più
che spontaneo dire che LVM è una merda, proprio perché sembra essere un
sistema pensato male e portato avanti peggio (occhio, con questo non voglio
dire che non funziona), ed è per questo che lo userei più per fare cose
semplici che non per altro
 
Enrico

 disco dedicato alla cache si rompe?
 
Volendo, crea tutto in automatico.
Il cosa succede nel caso si rompesse è proprio ciò che vorrei sapere anche io.

    sistema è che andrà più piano.
 
E questo chi dice che sia diverso dal caso LVM?
 
L'unico modo per avere un cache "a perdere", senza
mirroring, e` che scriva direttamente sul backend.
 
Il che rovina le prestazioni anche con cache attiva.
 
C'e` tutto un filone di discussione sul tema riguardo
"bcache", che ovviamente chiarisce dove sia il problema,
dove sia la soluzione e quale sia il costo.
 
bye,
 
-- 
 
piergiorgio

 dove sia la soluzione e quale sia il costo.
 
La soluzione per me è usare ZFS, poi ognuno fa come vuole
 
Enrico

 La soluzione per me è usare ZFS, poi ognuno fa come vuole
 
Personalmente, non conosco ZFS. Metterlo in produzione non mi farebbe dormire tranquillo.

 dormire tranquillo.
 
Non dormirei tranquillo nemmeno io, ma sicuramente dormirei più tranquillo di
quanto faccia con LVM (soprattutto quando vado ad usare funzionalità tipo
snapshot e lvmcache)
 
Enrico

 influire sulla stabilità del sistema, ma solo sulle sue prestazioni. Con
 
Qui ti sbagli, perche` il semplice fatto di aumentare la
complessita` del sistema (LVMcache, bcache, zfs) influisce
sulla stabilita`.
 
bye,
 
-- 
 
piergiorgio

 La soluzione per me è usare ZFS, poi ognuno fa come vuole
 
Hai verificato la differenza di prestazioni?
 
Quello e` il "costo".
 
bye,
 
-- 
 
piergiorgio

 sulla stabilita`.
 
GOTO 30
 
Enrico

    problema di stabilità.
 
Il prezzo che paghi per la tua supposta stabilita`
e` nelle prestazioni.
Ammesso che ZFS non perda dati senza dirti niente.
 
Quindi, il consiglio e` capire come esattamente
funzioni uno e l'altro, prima di commentare sul
quale sia piu` "stabile" o piu` "veloce".
 
Se ZFS usa COW, quando la cache si rompe, che
dati hai sul backend?
Funzionera` anche, ma avere un file vecchio,
*senza* neanche essere informati, mi pare
peggio che avere un crash completo.
 
Oppure, a scelta, il funzionamento e` piu` lento
(con la cache funzionante) per via della scrittura
diretta sul backend.
 
Ti ripeto, sulla mailing list di "bcache" si e`
discusso della cosa, pro e contro di avere una
cache "sicura".
 
bye,
 
-- 
 
piergiorgio

 Hai verificato la differenza di prestazioni?
 
Genericamente, posso dire che ZFS ha prestazioni molto buone. Usando un L2ARC
non so esprimermi, il test che ho fatto è su di una macchina virtuale che aveva
grosse limitazioni di I/O (anche con L2ARC attivo)
 
Enrico

 cache "sicura".
 
Occhio, bcache e lvmcache sono due cose differenti. Il primo fa caching anche
delle scritture (se non ho capito male), il secondo solo delle letture. In ogni
caso, mi piacerebbe leggere quella discussione
 
Enrico

 caso, mi piacerebbe leggere quella discussione
 
AFAIK, lvmcache velocizza anche le cache in scrittura.
Velocizzare solo la lettura, a meno che non ti servano centinaia di giga in cache, lo puoi fare benissimo con una buona quantità di RAM e lo fa il kernel in automatico.

 il kernel in automatico.
 
È evidente che la cache eseguita in RAM dal kernel non basta, altrimenti non
esisterebbero lvmcache, bcache e L2ARC (tra l'altro, tra le Project Ideas di
btrfs c'è proprio la richiesta di implementare un sistema di caching simile a
quelli citati, così come c'è la richiesta di implementare la possibilità di
usare uno o più dischi da dedicare alla gestione dei metadati)
 
Enrico

 Non mi sembra proprio, anzi, quello che tu prospetti è uno scenario in cui
 
Allora vuol dire che usa 1) ed e` piu` lento di chiunque
usi 3), molto semplice.
 
Nota che questo non e` un problema, e` semplicemente una
scelta conservativa, nella filosofia di ZFS, cioe` di
garantire la sicurezza dei dati in primis.
 
Nota ancora che, lvm-cache, in 1), *non* deve avere
problemi in caso di rimozione della cache, altrimenti
vi e` un problema (implementativo?).
 
Nota ulteriore, "bcache" vanta anche lui la sicurezza
dei dati, al punto che c'e` gente che stacca il cavo
SATA dell'SSD durante scritture random (con relativi
bug report e miglioramenti).
 
Nota a latere :-), "bcache" si puo` configurare in 3),
per chi vuole prendersi il rischio.
 
Nota ripetuta, lvm-cache e` consigliato in mirroring,
dagli stessi autori.
 
Quindi, per fare un confronto tra due sistemi (qualunque)
bisogna essere sicuri di essere nella stessa situazione.
Se ZFS e` in 1), allora anche l'altra cache deve essere 1),
perche` se e` 3) chiaramente non e` affidabile.
D'altro canto, se misuriamo prestazioni di "bache" in 3),
dobbiamo avere anche ZFS in 3) (se possibile).
 
bye,
 
-- 
 
piergiorgio

 Se ZFS e` in 1), allora anche l'altra cache deve essere 1),
 
Di default ZFS è in Write-through, così come lo è lvmcache
 
Enrico
P.S. lo riporto qua perché mi è difficile quotare il pezzo in cui lo hai detto:
personalmente, quando dici che gli sviluppatori di lvmcache non hanno considerato alcuni aspetti, personalmente per come vedo che è fatto LVM sembra un
castello di carte che si regge con lo sputo, finché funziona va bene, nel
momento in cui esci un po' dal seminato l'unica cosa che puoi fare è pregare

 Se ZFS e` in 1), allora anche l'altra cache deve essere 1),
 
Dimenticavo, qua trovi parecchi post che affrontano l'argomento ZFS soprattutto
su Linux (ma su FreeBSD e su Solaris rimane sostanzialmente identico) e sono
parecchio esplicativi: 
https://pthree.org/category/zfs/
 
 
Enrico

 momento in cui esci un po' dal seminato l'unica cosa che puoi fare è pregare
 
Il fatto semplice e basilare e` che lvmcache non e` finito.
Questo mi pareva fosse chiaro sin dall'inizio.
 
Il mio commento iniziale era sul metodo di confronto.
 
Come gia` scrivevo, non ho ancora visto un sistema di cache
che sia realmente "completo".
Cioe` che sia usabile e che abbia le feature che deve avere.
 
bye,
 
-- 
 
piergiorgio

 Potrei sbagliare, comunque.
 
O meglio, da quello che ricordo di aver letto
(che potrebbe essere sbagliato e/o obsoleto),
lvmcache e` in write-through fino a che un
blocco non viene promosso in cache. Da quel
momento, per quel blocco, e` in write-back.
 
La conseguenza diretta di questa cosa e` che
la cache non puo` garantire i dati in caso
di rottura, quindi, se si teme questo, si
devono prendere provvedimenti aggiuntivi.
 
Ora, questo puo` piacere o meno, essere
interessante o scomodo, e` comunque una
scelta valida come un'altra.
 
bye,
 
-- 
 
piergiorgio

 che sia realmente "completo".
 
ZFS lo è ;)
 
Enrico

 ZFS lo è ;)
 
No, se non puo` funzionare write-back.
No, perche` non consente di farlo a livello
di block device...
Detto altrimenti, non mi consente di usare
un filesystem diverso da ZFS.
No, perche` sospetto sia lento... :-)
No, perche` ZFS non e` flessibile.
 
Per es., bcache consiglia, in caso di RAID, di
assegnare la cache non al RAID, ma ai singoli
componenti.
D'altro canto e` piu pratico assegnarlo al RAID.
Quindi, l'utente puo` scegliere cosa meglio gli
aggrada.
Tanto per dirne una, si potrebbe fare un RAID
con 4 HDD e 4 SSD, dove ogni SSD e` cache di un
HDD i quali formano un RAID.
 
In conclusione, no ZFS e` meno completo degli
altri, per molti aspetti.
 
bye,
 
-- 
 
piergiorgio

 altri, per molti aspetti.
 
In conclusione, direi che non conosci ZFS e non sei interessato a capire come
funziona. Pertanto per me la discussione finisce qua, perché a mio avviso
oramai non porta più a nulla
 
Enrico

 oramai non porta più a nulla
 
Infatti, non ho mai scritto che lo conosco.
Ma ogni volta che discuto con qualcuno riguardo ZFS,
pare che esista solo quello e` il resto non conti.
Il che non mi pare porti avanti comunque la discussione...
 
bye,
 
-- 
 
piergiorgio

 ZFS implementa i ZVOL, che sono block devices a tutto tondo
 
Questa cosa mi interessa in modo particolare.
Non riesco, pero`, a trovare molte informazioni.
O meglio, informazioni dettagliate.
 
Hai qualche riferimento utile?
Qualcosa di piu` sostanzioso di questo:
 
https://docs.oracle.com/cd/E19253-01/819-5461/gaypf/
 
 
bye,
 
-- 
 
piergiorgio


Il problema di ZFS è che non è presente in maniera nativa nemmeno su Jessie.
Tendo a non considerare software aggiuntivo, sopratutto quando si tratta di filesystem. Quando tutto va a puttane (ed è proprio li che devi avere la massima praticità), potrei aver difficoltà a montare il FS da qualche macchina differente magari non aggiornatissima
 
In altre parole: tengo il culo lontano dai calci.
 
Altrimenti nessun problema ad usarlo, in quasi 10 anni che uso Linux dal punto di vista professionale, i miei unici interventi a livello di FS sono stati: mount, remount, umount, fsck, resize2fs. (più LVM)
Usare ZFS non dovrebbe essere molto diverso, ne dovrebbe richiedere chissà quali competenze, si presume che un FS maturo non richieda interventi magici da parte dell'utente.

 della cache...
 
Qui:
https://pthree.org/2012/12/06/zfs-administration-part-iii-the-zfs-intent-log/
 
 
e' spiegato molto bene come funziona ZIL, ARC, L2ARC ecc.
 
Ciao Jack

 e' spiegato molto bene come funziona ZIL, ARC, L2ARC ecc.
 
Interessante.
 
Da quello che ho capito, pero`, SLOG rimane
consistente perche` c'e` sempre una copia in
RAM. Cioe` non i dati non vengono "trasferiti",
ma "copiati" nella cache in attesa di passare
sul dispositivo piu` lento.
 
In pratica, fa il mirror tra cache e RAM.
 
bye,
 
-- 
 
piergiorgio