Newsgroup: it.comp.os.linux.sys
Titolo: Velocizzare fsck

Ho un volume di "piccole" dimensioni, solo 12TB :-) sul quale un fsck richiede in media 1-2 giorni.



C'è modo di velocizzarlo ? Ultimamente mi sta dando problemi, ad ogni reboot mi parte il check del disco (giustamente, il FS è realmente corrotto), sta fermo più di 1 giorno, il server si avvia, mi si corrompe di nuovo, riavvio e stessa manfrina.



Dato che anche in fase di fsck durante il boot il controllo viene riavviato più volte, l'ultimo "boot" è in fase di esecuzione da martedì. Aveva finito il controllo giovedì mattina per poi riavviarlo in automatico (lo fa fsck) ed è tutt'ora li che va.



Sapete com'è, il server mi servirebbe.......... Riavviarlo in fastboot non è una soluzione perchè 3/4 dei dati (di backup, quindi spazzatura) sono corrotti e non mi permetterebbe di accedervi o eliminarne. Devo eliminarli per forza perchè il software di backup che uso calcola il nome dei file basandosi su un hash, che per forza di cose è sempre lo stesso a parità di file. Avere un file corrotto con un nome che al software serve, rende il backup inutilizzabile, non potendolo scrivere.


 [...]



Lo so che non è la risposta che stai cercando, ma a queste condizioni

forse non ti conviene un bel formattone e via?  Se i dati sono di backup,

allora sei in peircolo solo quando hai bisogno di un restore, perciò la

soluzione veloce di formattare è buona.



Non so però nulla sul restante 1/4 del disco.


 Non so però nulla sul restante 1/4 del disco.



La parte restante mi serve, sono sempre backup, ma buoni.



Manca informazione importantina (o sono stordito io): di che tipo di 

filesystem stiamo parlando?

Altra risposta che non stai cercando: io avevo problemi analoghi con 

disconi ext3, e il passaggio a ext4 mi ha svoltato di molto le cose sul 

fronte fsck passando da ore fitte a relativamente pochi minuti (anche su 

disconi da 14Tb)

Morale: non ho consigli per velocizzarlo ma se parti da un ext3 voterei 

anch'io per un formattone + cambio fs




 filesystem stiamo parlando?



ext4 ma con journal disattivato



Per me il disco è rotto.


 C'è modo di velocizzarlo ? 



ZFS :) 



-- 

Massimiliano


 Per me il disco è rotto.



Non credo, perchè quando termina l'fsck poi i dati vengono scritti e letti correttamente.



Sono io che li corrompo perchè durante i backup creo raffiche di hardlink e un cazzone di programma mi fa piantare il server costringendomi ad un reboot forzato.



La corruzione è colpa mia, non del disco, ma il fatto che fsck impieghi 1 giorno abbondante a terminare il check di 12TB mi lascia perplesso. Se non è 1 giorno (24 ore) saranno 18, ma sempre troppe sono.


 costringendomi ad un reboot forzato.



Eliminare (o virtualizzare) il cazzone non ti potrebbe aiutare?



Bye.



Dipende come lo fai il reboot forzato, non credo con ctrl-alt-canc.

E poi con ext4 il check non dovrebbe durare tutto questo tempo.



Per me l'hd lo hai rotto tu, se gli togli l'alimentazione di colpo

mentre sta leggendo e/o scrivendo c'è sempre il rischio.



-- 

http://paskali80.antiblog.com





On 2016-01-15 11:10:02 +0000, 
gandalf.co...@gmail.com
 said:




C'è modo di velocizzarlo ?
 




Passare a ZFS?




;-)




--
 


Andrea






… devo ricordarmi di Leggere Il Finissimo Thread prima di rispondere.





-- 

Andrea





Forse non hai capito la mia risposta. 

- ZFS *non* ha alcun tipo di fsck, pertanto è "più veloce". 

- esiste ZFS per linux con i driver in kernel space, quindi volendo si può



-- 

Massimiliano Adamo



aahhh ... pardon. Adesso capisco la risposta che avevi dato a me :) 





-- 

Massimiliano Adamo


 - ZFS *non* ha alcun tipo di fsck, pertanto è "più veloce". 



veramente si, si chiama "scrub".



Ciao Jack



perche' hai disattivato il journal?

E' quello che ti evita che il sistema si corrompa in caso di reboot forzato ;)


 Eliminare (o virtualizzare) il cazzone non ti potrebbe aiutare?



Il "cazzone" è il software di backup, questo è un server di backup.

Eliminare il cazzone significa eliminare il server ;)



Il problema, ovviamente, è fixare il cazzone, ma nel frattempo, ogni 2x3 mi parte l'fsck che dura 2 giorni.


 E' quello che ti evita che il sistema si corrompa in caso di reboot forzato ;)



Guadagno circa 15-20MB/s senza journal.


 C'è modo di velocizzarlo ?



ahimé, se sei sicuro che dischi siano buoni, a parte andare di mkfs sul LV 

(perché, vedendo la dimensione, mi viene da dire che si tratta di un unico 

volume LVM) non è che tu abbia molte alternative. Ti consiglio inoltre di 

usare XFS, che in una situazione simile alla tua (un casino di hard link) 

non mi ha mai dato problemi



Enrico

P.S. sarebbe interessante capire perché hai disabilitato il journal...



Nella mia ignoranza mi chiedo: questa differenza throughput si fa sentire

molto come disagio? O ci sono altri colli di bottiglia?



A ben pensarci forse è accettabile avere l'overhead del journal se poi ti

salva da giorni di blocco dovuti a reboots e fsck.


 salva da giorni di blocco dovuti a reboots e fsck.



A dire il vero, i problemi li avevo anche prima di disattivare il journal.

A dire il vero 2, anche su altri server, in caso di reboot brutale, journal o non journal, fsck fa comunque il check del disco (non ho mai capito perchè)



Il passaggio ad XFS è in programma, ma prima di voler piallare tutto il mondo perdendo tutti i backup (non saprei dove altro posizionarli, sono 12TB), volevo mettere in piedi la nuova struttura, testata e funzionante, poi piallo, faccio esegire subito un backup di tutti i server coinvolti.


 Guadagno circa 15-20MB/s senza journal.



Non puoi spostarlo sud i un altro disco? Magari connesso con un 

controller differente?



Enrico


 controller differente?



Per come è fatto il server no. E' vecchio, ho solo 1 gigantesco raid-5 hardware sopra il quale ho creato dei volumi. Grossissimo per il backup, piccolini per tutto il resto del sistema.



Spostarlo impatterebbe comunque lo stesso controller e lo stesso raid, libererebbe solo il volume del backup, ma non ho spazio per aggiungere volumi extra e nel caso fosse possibile creare il journal come file (non lo so, mai fatto) dovrei metterlo in partizioni piccoline....



Per me la soluzione è passare a XFS, ma prima devo mettere in piedi il sistema, poi formattare. E se ogni 2x3 devo reboottare e far partire fsck, ci metto mesi. Comunque, al momento sembra stabile da qualche giorno. Forse aveva bisogno di far finire per intero l'fsck riavviandolo un paio di volte in automatico.


 un paio di volte in automatico.



Ci sono solo due modi per far piantare un sistema Linux: guasto hardware o 

software in kernel space (o che gira come root).



Non so che sistema di backup tu abbia, ma se gira come root o in kernel 

space è ora di cambiarlo, e se non lo fa, allora il problema è quasi 

sicuramente hardware.



Cambiare fs non aiuterebbe, in questo caso.



Bye.


 Cambiare fs non aiuterebbe, in questo caso.



Secondo me è un problema di carenza risorse, nel mio caso.

Inizia a frullare a manetta, con load spaventoso, rendendomi obbligato a riavviare, perchè da quel load non si schioda per parecchi giorni.



Ma dovrei aver risolto, ora sembra stabile (non si pianta), appena capisco come funziona (e se funziona come intendo io), piallo tutto e riparto.


 capito perchè)



Perché è giusto così. La differenza tra journal e non journal è che in 

caso sia presente viene eseguito prima un check su di esso e poi, se 

necessario (ovvero anche il journal si è corrotto pesantemente), su tutto 

il disco



Enrico


 ha scritto:



 il disco



Allora sono proprio sfigato.....


 Allora sono proprio sfigato.....



Non è che sei sfigato, è che non hai il journal e quindi fsck si comporta 

di conseguenza (analizza tutto il disco) :)



Enrico

P.S. non è che con XFS non hai più bisogno di journal o di fsck, eh, 

semplicemente sono operazioni più veloci o necessarie solo nel momento in 

cui qualcosa va *veramente* male


 di conseguenza (analizza tutto il disco) :)



Intendevo in altre macchine con journal attivo (ovvero tutte tranne questa).

In tutte ogni volta mi parte l'fsck completo, per questo dicevo di essere sfigato.


 riavviare, perchè da quel load non si schioda per parecchi giorni.



OK, allora non è lui che muore, ma tu che lo uccidi. :)



Hai swap attiva? Prova a toglierla.

Il software di backup lavora in multi-threading o multi-tasking? O 

comunque viene invocato diverse volte in parallelo? Abbassa la 

concorrenza, possibilmente a 1, tanto di "disco" ne hai uno.



Bye.


 veramente si, si chiama "scrub".



eh ma non è uguale, altrimenti lo avrebbero chiamato fsck.zfs

scrubbing è un tentativo di accesso a tutti i dati, blocco per blocco, per 

vedere se sono accessibili. 



-- 

Massimiliano Adamo



fortunatamente non e' uguale, altrimenti vorrebbe dire che zfs come fs e' una chiavica quanto gli ext...



Ciao Jack


 



ormai si puo' dire tranquillamente che gli ext* sono una chiavica senza 

rischiare di urtare la suscettibilita' dei presenti :) 

Se lo avessi detto qualche anno addietro avresti rischiato il linciaggio. 



Ext* sono una cagata pazzesca :)



  Io mi sarei limitato a dire che sono stati superati dall'evoluzione

dei filesystem per uso enterprise e datacenter!  :-)





  Ciao,





-- 

Alessandro Selli 
http://alessandro.route-add.net


AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.

WARNING: messages sent to "trappola" will never reach me.






Premesso che non voglio innescare flame ma vorrei solo cercare di capire 

i motivi pareri professionali così tranchant (anche perché mi ritrovo 

con partizioni dati prevalentemente in ext4 e mi avete fatto venire le 

pare), mi pareva che neanche troppo tempo ext4 avesse ancora qualcosa da 

dire a livello enterprise in alcuni campi:

http://blog.pgaddict.com/posts/postgresql-performance-on-ext4-and-xfs




Vedo che pure RHEL 7 ora propone xfs come default, non è che questioni 

che ext4 sia avviato verso la pensione, ma mi pareva (ma evidentemente 

mi sfugge qualcosa) che a livello di casi d'uso lo scarto non fosse 

(ancora) così epocale.






 (ancora) così epocale.





guarda, io ho scritto ext*, ed effettivamente potrebbe anche sembrare che 

ho esagerato. Ma in realtà non credo di aver esagerato. 

ext2 era un disastro totale dal punto di vista della solidità/resistenza. 

con ext3 fu introdotto il journal, ma la stabilità era ancora lontana da 

venire. 

ext4 va chiaramente meglio, ma è arrivato fuori tempo massimo. 



Ti basta pensare, che l'XFS che viene usato oggi è un filesystem di SGI 

per IRIX creato nel 1993 ed ha pure una versione cluster (CXFS). 

Chiaramente, non credo che la versione di oggi sia la stessa di 25 anni 

fa, però, posso dire che le caratteristiche di oggi sono le stesse di 

quelle che io ricordo 15 anni fa. Solo che 15 anni fa non era stabile su 

Linux ma era stabile su IRIX. 



Insomma, finalmente Red Hat può usare una tecnologia vecchia di almeno 15 

anni :) 

L'idea, oggi' è di usare ZFS, o di sperare che un domani BTRFS diventi più 

stabile. 



-- 

Massimiliano Adamo


opensuse 42.1 usa di default:



"Btrfs is the default filesystem for root, and XFS for the /home directory"



fa sperare bene



https://en.opensuse.org/Features#Changes_In_Filesystems



 fa sperare bene



Speri male



Enrico



sono d'accordo con te. 

Mi pare di capire che è cambiata la licenza di ZFS, e a quel punto si è 

perso l'entusiasmo nel progetto BTRFS: non ha più senso reinventare la 

ruota. 



-- 

Massimiliano Adamo



Secondo "l'oracolo" (Wikipedia) non e` proprio cosi`:



Linux



ZFS has several Linux implementations despite the fact that the GNU

General Public License (GPL), under which the Linux kernel is licensed,

is incompatible with the Common Development and Distribution License

(CDDL) under which ZFS is distributed.[88] According to the used

licensing models, a single derived work of both projects cannot be

legally distributed, as it is not possible to simultaneously meet both

licenses' requirements.[89] To include ZFS in the Linux kernel, ZFS

would have to be cleanly reimplemented, and patents may hamper this.



This problem is being worked around by providing the kernel facilities

through a separate kernel module, a technical solution for a legal

problem that is also being employed by vendors and distributors of

proprietary hardware drivers.



C'e` anche "zfs-fuse", ma questo, ovviamente, non conta.



"btrfs" e` GPL, invece.



Quindi, almeno per il momento, e` piu` "comodo" questo

secondo, almeno per la licenza.



bye,



-- 



piergiorgio


 secondo, almeno per la licenza. 



Ce l'hai un DB Oracle in azienda, un qualsiasi altro software con licenza 

diversa da GPL, un Office, un Outlook, una licenza Windoze qualsiasi, una VPN 

che non sia openvpn, un editor che non sie free? 

Dico uno tra tutti questi, non ce l'hai in azienda? 

A me piace tantissimo la licenza GPL*, ma veramente dobbiamo farci ancora le 

pippe con queste cose semplicemente assurde? Vuoi per caso cambiare il mondo

con l'informatica?  



La realta' e' che in azienda nessuno si fa di queste pippe. 

Nella mia azienda, ad esempio, abbiamo tutti i server MySQL su Linux con ZFS, 

perche' le perfomance con gli snapshot sono ottime. Facciamo uno snapshot ogni 

15 minuti e conserviamo 48 snapshot. 



Per quanto riguarda btrfs ti cito cio' che e' successo a me. 

I chunk erano mis-blanaced ed il filesystem risultava pieno con un utilizzo 

sotto il 50%. Essendo arrivato al 100% era impossibile liberarlo e dovevo fare 

una cosa del genere: 



btrfs balance start -dusage=XX /mnt/btrfs_pool



piu' o meno all'infinito, provando con diversi valori per XX



Useresti btrfs in produzione con 48 snapshot? Ma anche no. 




 La realta' e' che in azienda nessuno si fa di queste pippe. 



Non hai capito niente.



Il fatto che btrfs sia GPL non e` un vezzo,

una piacevolezza, ne` una mia particolare

fissazione.

E` semplicemente la condizione sine qua non

un pezzo di SW viene integrato e mantenuto

dalla comunita` Linux.

La cosa puo` piacere o meno, ma e` cosi`.



Il problema di zfs, e la ragione per cui

btrfs esiste, e` proprio che la CDDL non

e` GPL compatibile e quindi una buona parte

degli sviluppatori Linux non vuole averne a

che fare e quindi non conviene fare troppo

affidamento su di quel software.

Perche` prima o poi, se la licenza di zfs non

cambia, btrfs diventera` mainstream.

Per forza di cose, non perche` la GPL sia

meglio, semplicemente perche` e` la licenza

che la (maggioranza della) comunita` vuole.



Lo stesso discorso si applica a cdrecord,

tra l'altro.



bye,



-- 



piergiorgio


 e` la licenza che la (maggioranza della) comunita` vuole.



La fai più semplice di quel che è. 

RedHat è finalmente approdata a XFS, una tecnologia sorpassata, con 

caratteristiche vecchie di 15 anni ed il cui sviluppo cominciò nel 1993. 

Altra questione da non sottovalutare, BTRFS era nato per volontà di Oracle 

diversi anni fa, ed Oracle resta ancora oggi il principale sviluppatore 

(basta guardare su wikipedia: Sviluppatore -> Oracle Corporation). Ma 

quale può essere oggi l'interesse di Oracle, dopo che hanno acquisito Sun 

e possiedono ZFS? 



La verità è che la community, in 20 anni, è finalmente riuscita ad 

offrirci ext4 e per offrirci btrfs, in uno stato decente, dovremo 

aspettare non si ancora quanto tempo. 





Ulteriore questione, molto importante. In RH, usano anche loro prodotti 

closed source, anche prodotti di terze parti source, che richiedono 

l'acquisto di costose licenze. Per satellite suggeriscono l'utilizzo di un 

DB Oracle. Red Hat Enterprise Virtualization si installa su un server 

Windows!!!undici-unici

Laonde e per cui, se loro non si fanno pippe, ma perché te le devi fare 

tu? 



-- 

Massimiliano Adamo


 tu? 



Ma cosa scrivi? Non c'entra nulla.

I prodotti commerciali associati a RH non sono

pezzi del kernel sviluppati dalla comunita`,

sono SW commerciali, appunto.

E` una storia completamente diversa.



E ti ripeto che il discorso licenza non e` una

mia preferenza, bensi` della comunita`.



Tu non vuoi capire che qualunque SW che vuole

fare parte integrante del kernel di Linux *deve*

avere una licenza compatibile.

Il resto, prima o poi, muore, perche` gli sviluppatori

tendono a non sostenere quello che non soddisfa quel

requisito legale.



btrfs e` nel kernel (sostenuto da RH), mentre zfs non

lo e`. Questo e` un dato di fatto.



Che tu possa scaricarti un modulo ed installare un

dkms zfs e` la prova che viene ignorato e sopravvive

solo per terze parti.

Il che` e` *male* per il futuro.



bye,



-- 



piergiorgio


 Il che` e` *male* per il futuro.



Pazienza. 

Vuol dire che in futuro se avrai avuto ragione tu dovrò fare apt-get 

remove. Ma io non posso attendere il futuro per usare decentemente gli 

snapshot. 





-- 

Massimiliano Adamo


 snapshot. 



Basta usare LVM ed hai gli snapshot, senza

fissarti su un fs specifico, persino.

Magari usando un fs, come xfs, che sicuramente

e` piu` collaudato ed ha meno bug.



bye,



-- 



piergiorgio


 e` piu` collaudato ed ha meno bug.



prova LVM con 48 snapshot e poi ne riparliamo. 




 > On 2016-02-17 23:35, Max_Adamo wrote:



[CUT]



vorrei semplificare questa discussione se me lo concedi. 

Ho appena scoperto che git ha una nuove opzione "sparse-checkout" ma sono su

una rete lenta e sparse-checkout, scarica comunque gli oggetti, anche se non fa 

il pull e richiede troppo tempo. Non mi interessa piu' contare i commit. 

Possiamo convenire tranquillamente su delle questioni che sono abbastanza 

ovvie e condivisibili: 

- zfs non sara' mai dominante, fin quando non cambia la licenza e non sara' 

distribuito con il kernel (VERO!)

- considerando che lo sviluppo di XFS comincio' nel 1993 e quello di ZFS nel

2001, quali sono i tempi per avere btrfs ai livelli di zfs? Saremo gia' in 

pensione? 10 anni? 20 anni? Ne riparliamo nel 2026 o nel 2036? (DIFFICILE 

RISPONDERE!)

- usare ZFS per un progetto, oggi va benissimo. Sei sicuro che almeno per i 

prossimi 5 anni non ci sara' nessun prodotto concorrente in grado di 

rimpiazzarlo. Tra 5 anni non ci saranno piu' nemmeno i server e lo storage che

avevi usato per quel progetto. (VERO!)


 vorrei semplificare questa discussione se me lo concedi. 



una chicca. 



i commit sono un po' di piu' per btrfs. Poca cosa (4mila contro 4800 contro 5200), laddove ZFS e' un piu' semplice porting. 

Quasi il 50% dei commit sono fatti da Oracle (Chris Mason). 

La parte rimanente e' costituita da merge di pull request fatte sempre da Chris 

Mason. 

A un certo punto Chris Mason cambia lavoro e va in facebook. Un'altra parte

dei commit sono sempre suoi. 

Diciamo che il 75% del lavoro e' di Chris Mason. 

Se Chris Mason dovesse uccidere la sua ragazza, btrfs farebbe la stessa fine di 

reiserfs :)


 con l'informatica?

So che dicendolo mi farò male, ma se queste sono pippe, allora anche 

rispettare la GPL (es.: rendere pubbliche le modifiche apportate) è una 

pippa mentale.



Inizio e termino qui.


 Inizio e termino qui.



Sarebbe comodo ma non credo andrà così. ;-)



-- 

Andrea




 Inizio e termino qui.



penso che mi hai frainteso. La penso come te.  



-- 

Massimiliano Adamo


 Sarebbe comodo ma non credo andrà così. ;-)



infatti :) 



Ma non so a voi, ma a me fa piacere.... il gruppo è così talmente smorto 

di questi tempi che questo sono botte di vita necessarie per la sua 

sopravvivenza :) 



-- 

Massimiliano Adamo


 infatti :)



The internet is for flame.





-- 

Andrea




 fissarti su un fs specifico, persino.



Ad oggi, se mi interessassero gli snapshot, paradossalmente userei Btrfs.

Perché, a conti fatti, è un ottimo sostituto di LVM mentre non lo è per mdadm (e

perché da quando lo ha usato Adamo sono cambiate parecchie cose)



Enrico


 Diciamo che il 75% del lavoro e' di Chris Mason. 



Ecco, hai centrato un punto focale dello sviluppo di Btrfs: non c'è un vero team

dietro ma c'è uno one-man-band. Il che è male, indipendentemente dal progetto



Enrico


 della licenza.



Tra poco lo si avrà anche su Linux:

http://blog.dustinkirkland.com/2016/02/zfs-is-fs-for-containers-in-ubuntu-1604.html




Enrico

P.S. spero che estenderanno il discorso anche all'installer, che avere una root

su ZFS non mi dispiacerebbe proprio...


 



Eh, la questione "supporto" aveva difatti poco senso per me perché 

linux non è un sistema operativo.

Se una distribuzione lo offre tra i pacchetti di base ecco che c'è il 

supporto _per quel sistema_, l'utente finale si interfaccia con il 

sistema operativo, non con linux, quindi basta che ci sia il pacchetto 

nella distribuzione ed è assolutamente indifferente se faccia parte del 

kernel o meno.



La questione del supporto inteso come "risolvono i bug" non si pone 

perchè la comunità di Illumos, per quanto piccola, è attiva (e non è un 

one-man show), così come un bug btrfs viene (forse) risolto così viene 

risolto in zfs.



Interessante che Canonical si muova in questo senso, non so perchè 

ricordavo che RedHat già lo faceva ma non trovo conferme in rete.





-- 

Andrea




 ricordavo che RedHat già lo faceva ma non trovo conferme in rete.



Che io sappia RH spinge btrfs, proprio per la

questione CDDL di zfs.



bye,



-- 



piergiorgio


 
http://blog.dustinkirkland.com/2016/02/zfs-is-fs-for-containers-in-ubuntu-1604.html




No, ci sara` su Ubuntu... :-)



Quello che sto cercando di spiegare e` che in

qualunque relazione con fornitori, e` normale

prassi avere un "second source", "second supplier"

o "secondo fonte".

Se facciamo scarpe, e` raccomandabile avere almeno

due fornitori di stringhe.

Alcune ditte impongono la cosa nell'acquisto di

componenti.

Altre addirittura impongono 80/20 su due fornitori.



Ora, nel caso di SO, come scritto gia`, avevamo un

"single supplier" e non ci e` piaciuto.



Adesso arrivata Ubuntu con zfs (nota zfs, non un

applicativo ignorabile) e diventa *single supplier*

per quel modulo.



Se arriva un problema, con zfs od altro, *dobbiamo*

rivolgerci a loro (per il loro sistema).

Non c'e` un "second source", non e`neanche possibile

riprodurre la cosa con un'altra distribuzione simile.



Ovviamente, se RH, OpenSuse, Ubuntu e quanti altri

iniziassero tutti a distribuire zfs, la cosa sarebbe

diversa, ma al momento non e` cosi`.



Ora, perche` non e` cosi`?



Il problema e` la CDDL, che Canonical ignora, forse

anche violando la GPL, ma altri no.



Ovviamente, supponendo che zfs sia effettivamente

ancora sotto CDDL.



E ripeto, il problema e` che zfs e` un componente

critico, non e` un media player, un office od altro

che puo` essere ignorato / sostituito.

Ovviamente, qualcuno puo` pensare di sostituirlo con

btrfs, YMMV...



bye,



-- 



piergiorgio



In generale, preferisco usare "stacked component".



Il problema, gia` noto da prima di Linux, e` che

mettere assieme una marea di moduli conduce sempre

a problemi nascosti, che prima o poi diventano

critici, con conseguenza fatali.



Integrare il browser nel SO non e` una buona idea,

non si diceva cosi`?



Allo stesso modo integrare md-lvm-fs e quanto altro

in un unico SW non lo e`.



bye,



-- 



piergiorgio


 questione CDDL di zfs.



Probabilmente ricordavo male.





-- 

Andrea




 btrfs, YMMV...



Non è un componente obbligatorio, non vuoi ZFS? Usi un altro fs a 

piacere e amen. Chiaramente potresti non avere le stesse 

caratteristiche ma è già così tra i vari fs.





-- 

Andrea




 in un unico SW non lo e`.



C'è un motivo di progetto per cui è stato concepito così.



C'è un video, non mi ricordo se "The Last Word in File Systems" o uno 

di Sun (forse con Cantrill) che fa una parentesi storica della 

concezione del fs legata al disco proveniente da IBM degli anni '60 e 

la paragona ai principi di progetti di ZFS in Sun, è su youtube.



È proprio la concezione "vecchia" dei fs il motivo per cui lvm e md 

sono stati sviluppati come componenti separati, non poteva essere 

altrimenti. (o almeno questo mi ha detto youtube)





-- 

Andrea




 Chi sono il single supplier e il second source in questo caso?



In quale caso?

Nel caso di Linux per se, hai una marea di

second source, a vari livelli.

Puoi installare Ubuntu o RH, CentoOS, magari

OpenSUSE (non saprei).

In piu` vari componenti hanno second source,

cioe`, per es., i kernel developers.



Nel caso di zfs, hai un single source.



Almeno fino a quando non diventa diffuso,

in un modo o nel altro.



Ovviamente, adesso, con Ubuntu, vi sono due

fornitori, ma, credo, si perdono quelli del

kernel, che di solito sono schizzinosi con

componenti non ufficiali.



bye,



-- 



piergiorgio



Diciamo che e` pubblicita` per l'integrazione

di concetti diversi in un unico SW.



Detto altrimenti, la *scusa* che md/lvm siano

patch per file system obsoleti consente di

concludere che il nuovo zfs/btrfs sia meglio.



Ma il problema va oltre il fs stesso.

E` una questione di come si sviluppa il SW.

Sicuramente e` meglio avere moduli separati

piuttosto che mettere tutto assieme.



Il vantaggio di avere integrate le interfacce

e` che consente di ottimizzare il tutto.

Moduli separati devono usare interfacce standard,

che hanno, per forza di cose, limiti (se non altro

prestazionali).



D'altro canto, pero`, avere interfacce standard

e moduli separati consente un sviluppo piu` facile,

un testing migliore e una distribuzione dei bug

meno critica.



Allora, dipende da cosa si vuole avere.



Dato che questi fs hanno come premessa la sicurezza

dei dati (e non le prestazioni), sarebbe meglio

avere i componenti piu` separati possibile.



bye,



-- 



piergiorgio


 ma è già così tra i vari fs.



Appunto, non e` obbligatorio, ma e` critico

se decido di usarlo.



bye,



-- 



piergiorgio


 distribuzione che usi che fai?



Debian - If you can't apt-get something, it isn't useful or doesn't exist.






 un testing migliore e una distribuzione dei bug meno critica.



e già, si vede come mdadm, lvm e fs sono migliori di ZFS :) 



queste sono altre pippe sulle pippe, e per di più pippe non supportate da 

fatti concreti. 

L'unica realtà che possiamo misurare, sono tool unificati e semplici da 

usare. Il restono sono .... ? Cosa sono? pippe :) 





-- 

Massimiliano Adamo



discorso non valido nel caso di zfs, perché non hai il raid 5, 6 ma hai 

raid-z, striped arrays, mirror.... e non sono sperimentali. 



-- 

Massimiliano Adamo


 No, ci sara` su Ubuntu... :-) 



ti ripeto, in modo stringato, che non importa se il kernel ha 10mila 

maintainers. 

Ognuno ha competenze per la propria nicchia, e chi ha fatto il driver per 

la scheda di rete o per la scheda audio, non si tocca il codice dei 

filesystem.

Per quanto riguarda btrfs, il gruppo che lo supporta consiste in una 

decina di persona, che poi si riducono ad un paio (oltre Chris Mason). 



A me, la situazione del supporto, sembra ben più critica con btrfs. 





-- 

Massimiliano Adamo



Perfetto. Allora il problema per zfs (con ubuntu e altre distribuzioni) 

non si pone:



$ apt-cache search zfs-dkms

zfs-dkms - Native OpenZFS filesystem kernel modules for Linux





-- 

Massimiliano Adamo


 monopolio sul SO da parte di un'azienda.



su quella vicenda del browser (che hai citato prima) e sul modo in cui è 

stata gestita, stenderei un pietoso velo. 



Sono d'accordo che il monopolio era sbagliato, ma prova a togliere google 

chrome da un chrome notebook e poi ne riparliamo. 

Anche KDE ha un browser che si integra con il file-manager. Quindi pure 

linux è colpevole.  

Anche OSX viene rilasciato con Safari e la sua disinstallazione non è ne 

esente da rischi. 

Anche android viene rilasciato spesso con il browser chrome (installato 

come app di sistema che può' essere rimossa solo con permessi root). Ma 

quantomeno, Android viene customizzato dai vendor, e in alcuni dispositivi 

il browser è differente. 





-- 

Massimiliano Adamo


 usare. Il restono sono .... ? Cosa sono? pippe :) 



Se per te perdere dati sono pippe, allora sara`

come dici tu.



Per me assicurarsi che un sistema funzioni e`

una cosa seria.



I tool unificati sono pericolosi e questo e` un

fatto *concreto* dimostrato da anni di esperienza.

Se tu dimentichi il passato, avrai problemi in futuro.



bye,



-- 



piergiorgio


 avevi usato per quel progetto. (VERO!)



Su questo punto, invece, non siamo d'accordo.



zfs, per me, non e` affidabile.

Sia per architettura, che per distribuzione.



E dire "non ho mai perso dati con zfs", non conta

molto, visto che io non ho mai perso dati ne` con

FAT, NTFS, ext123456, xfs...

Potrebbe contare qualcosa tipo: "avrei perso i dati

con fsXY, ma siccome c'era zfs mi sono salvato".



Io, per quel che mi riguarda, avrei potuto perdere

dati, ma mi sono salvato grazie a "md"...



zfs potrebbe diventare affidabile qualora entrasse

nel kernel in maniera ufficiale.



Per chiarire, "affidabile" non vuol dire solo in

senso di sw robusto e senza (con pochi) bug.

Bensi` vuol dire un sw su cui si possa fare

affidamento... :-)



A mio avviso, quello che rende meno pericoloso

zfs e` FreeNAS.

Perche` consente di avere una base, sia per

testing che per sviluppo, piuttosto vasta.

Per quanto "vasto" possa essere FreeNAS.



bye,



-- 



piergiorgio


 il browser è differente. 



Sempre in sintonia.



Sono tutto esempi corretti di un comportamento

sbagliato.



Tu non hai idea di quanto mi stia sulle scatole

KDE proprio per la mania di integrare tutto.

E Gnome segue a ruota.



Per prima cosa, diventa limitante della scelta

del SW. Usare, chesso`, il browser X, invece di

quello "ufficiale" diventa un problema, cosi`

tocca usare quello ufficiale.

Di conseguenza, tutti i bug diventano correlati

e si aumenta il rischio di problemi seri.

Secondariamente, come gia` scritto, si e` costretti

a rivolgersi sempre allo stesso fornitore.

Cosa, ovviamente, intenzionale (vendor lock).



bye,



-- 



piergiorgio


 A me, la situazione del supporto, sembra ben più critica con btrfs. 



Sicuramente.

Il fatto che btrfs sia in condizioni critiche non

alza il livello di zfs, pero`.



Non e` che se il tuo concorrente fa porcherie,

vuol dire che il tuo prodotto sia *il* meglio.

Forse e` solo migliore...



Se tu poni il termini di confronto di zfs con

btrfs, sicuramente, allo stato attuale, dovendo

scegliere fra i due, prendo zfs.



Dovendo scegliere, pero`, tra tutto il resto e

zfs, prendo tutto il resto (escluso btrfs).



Quello che ho scritto inizialmente, se non fosse

stato chiaro, e` che btrfs ha piu` possibilita`

di imporsi, in quanto presente nel kernel.



Questo non vuol dire che si imporra`, vi sono

diversi pezzi del kernel che sono volati via

per ragioni disparate, tra cui la mancanza di

maintainer.



bye,



-- 



piergiorgio


 come dici tu.



tu, tu che vieni dall'esperienza di ext2 e poi ext3, hai il coraggio di 

parlare di perdita di dati con zfs? 

I FS in Linux sono diventati stabili appena ieri e questa affermazione mi 

sembra abbastanza fuori luogo e mi fa un po' sorridere. 



-- 

Massimiliano Adamo


 non ho mai perso dati ne` con FAT, NTFS, ext123456, xfs... 



menti se dici non aver mai visto nulla nella lost+found con ext2. 



-- 

Massimiliano Adamo


On 2016-02-20 12:04, Max_Adamo wrote:


Calma e sangue freddo.



Non ho mai visto niente in lost+found per *colpa* di ext2.



Che poi il PC possa crashare perche` il driver "single

source" della scheda video e` farlocco e, di conseguenza,

vi siano file in lost+found e` un altro discorso.



Ho avuto problemi con il fs (qualunque) per altri

problemi riguardanti l'HW, il particolare la memoria.



Ed in questo caso vale il garbage-in garbage-out,

per cui nessun fs diventa immune da tali perdite

di dati.



Motivo per cui raccomando sempre di usare RAM ECC

per i dispositivi storage (e non).



bye,



-- 



piergiorgio


 sembra abbastanza fuori luogo e mi fa un po' sorridere. 



Cioe`, praticamente, tutti gli sviluppatori

Linux non sono in grado di fare un fs stabile

in 20 anni di sviluppo, e, tutto d'un tratto,

viene fuori zfs *stabile* in meta` tempo,

sviluppato da meno persone, per giunta.



Interessante, sono davvero dei geni questi di zfs.

Dovrebbe scrivere driver per le schede video...



bye,



-- 



piergiorgio


 Non ho mai visto niente in lost+found per *colpa* di ext2. 



sarà il caso ma io non mai visto nulla nella lost+found con ext4. 



Per quanto riguarda ext2, non c'è bisogno di problemi hardware. Non aveva 

il journale ed era sufficiente un kernel panic, una macchina senza UPS, 

una macchina virtuale che viene riavviata con le cattive maniera e la lost

+found si popola all'istante. 



Menti :) 



-- 

Massimiliano Adamo


 Dovrebbe scrivere driver per le schede video...



hint: il fondatore di Nvidia è un ex dipendente di Sun ;) 





-- 

Massimiliano Adamo



Oddio, allora si spiega tutto!!! :-)



Buon fine settimana...



bye,



-- 



piergiorgio


 Menti :) 



Sapendo di mentolo... eh... :-)



bye,



-- 



piergiorgio


 Oddio, allora si spiega tutto!!! :-)





comunque è vero... mi ricordavo di averlo letto da qualche parte:

https://en.wikipedia.org/wiki/Chris_Malachowsky
 :-)





-- 

Massimiliano Adamo


 Infatti lo sono.



No, non lo sono. Pensa ad esempio alla gestione degli snapshot. In ZFS (e

Btrfs) è basata totalmente sulle funzionalità CoW del file system, pertanto la

richiesta di uno snapshot equivale semplicemente ad assegnare una "label" allo

stato attuale e continuare le operazioni di scrittura come se nulla fosse (se

vogliamo fare un paragone azzardato, è come assegnare un tag ad un repository

git). In LVM, prima di tutto bisogna tenere conto del file system, in quanto

sia ext che XFS non supportano CoW (io lo dico sempre, su questo aspetto Ts'o

s'è cacato in mano, visto che lo aveva già pronto con ext3cow e significava

solo integrarlo in ext4), dopodiché la gestione si complica decisamente.

Per spiegartela, guarda questo:



[root@test ~]# dd if=/dev/zero of=disk1 bs=1 count=1 seek=512M

1+0 records in

1+0 records out

1 byte (1 B) copied, 0.000640765 s, 1.6 kB/s

[root@test ~]# dd if=/dev/zero of=disk2 bs=1 count=1 seek=512M

1+0 records in

1+0 records out

1 byte (1 B) copied, 0.000732079 s, 1.4 kB/s

[root@test ~]# dd if=/dev/zero of=disk2 bs=1 count=1 seek=512M

1+0 records in

1+0 records out

1 byte (1 B) copied, 0.000732079 s, 1.4 kB/s

[root@test ~]# losetup /dev/loop0 disk1

losetup: disk1: warning: file does not fit into a 512-byte sector the end of the file will be ignored.

[root@test ~]# losetup /dev/loop1 disk2

losetup: disk2: warning: file does not fit into a 512-byte sector the end of the file will be ignored.

[root@test ~]# pvcreate /dev/loop0 

  Physical volume "/dev/loop0" successfully created

[root@test ~]# pvcreate /dev/loop1

  Physical volume "/dev/loop1" successfully created

[root@test ~]# vgcreate testsnap /dev/loop[01]

  Volume group "testsnap" successfully created

[root@test ~]# pvs|grep testsnap

  /dev/loop0 testsnap lvm2 a--  508.00m 508.00m

  /dev/loop1 testsnap lvm2 a--  508.00m 508.00m

[root@test ~]# lvcreate -n lvsnap -l 100 testsnap

  Logical volume "lvsnap" created.

[root@test ~]# lvs|grep testsnap

  lvsnap testsnap -wi-a----- 400.00m

[root@test ~]# dmsetup table|grep testsnap

testsnap-lvsnap: 0 819200 linear 7:0 2048

[root@test ~]# lvcreate -s -n snap1 -l 30 /dev/testsnap/lvsnap 

  Logical volume "snap1" created.

[root@test ~]# lvs|grep testsnap

  lvsnap testsnap owi-a-s--- 400.00m                                                    

  snap1  testsnap swi-a-s--- 120.00m      lvsnap 0.00



[root@test ~]# dmsetup table|grep testsnap

testsnap-snap1: 0 819200 snapshot 253:3 253:4 P 8

testsnap-lvsnap-real: 0 819200 linear 7:0 2048

testsnap-snap1-cow: 0 245760 linear 7:1 2048

testsnap-lvsnap: 0 819200 snapshot-origin 253:3

[root@test ~]#



Praticamente, cosa succede: nella creazione dello snapshot, LVM:

 - Rinomina il volume lvsnap in lvsnap-real;

 - Crea un volume lvsnap in cui vengono scritte le nuove modifiche;

 - Crea un volume snap1-cow che contiene i vecchi dati del volume;

 - Crea un volume snap1 che contiene lo snapshot;



Di fatto è un ammasso di operazioni che non ha senso, perché LVM deve prevedere

qualcosa che non sa e di cui non ha gestione, con conseguente fragilità del

sistema



Enrico


 sistema



Che lo snapshot sia meglio a livello di fs si

era gia` discusso tempo fa, ed e` vero, per il

semplice motivo che solo il fs sa in che stato

sono i file.

D'altro canto funziona anche con LVM, quindi

non e` che sia proprio un problema.



Ma LVM non e` solo snapshot, ed inoltre c'e`

anche md nell'equazione.

Con LVM puoi avere lvmcache, lvm pool, etc.



Quindi, si, md+lvm+fs e` meglio di zfs, perche`

offre piu` funzionalita` in maniera piu` sicura.

Al massimo criticherei lvm RAID... :-)



L'unica possibile critica, snapshot a parte, e`

che bisogna imparare 3 set di comandi.

Di questo si lamentava Max.

E sotto un certo punto di vista potrebbe anche

aver ragione, perche`, sempre avendo in mente

la sicurezza, dovendo imparare di piu`, c'e` il

rischio di fare piu` errori.



bye,



-- 



piergiorgio


 No, non lo sono. Pensa ad esempio alla gestione degli snapshot. In 



[CUT]



Chapeau veramente!



L'ultima parte non mi era chiara fino a questo momento (disconoscevo i 

dettagli), ma evidentemente era chiara al mio collega quando mi disse che 

con LVM non poteva gestire 48 snapshot. 

Questo è praticamente il nostro backup con MySQL: uno snapshot ogni 15 

minuti per 12 ore. 



-- 

Massimiliano Adamo


 rischio di fare piu` errori.



E non c'è di mezzo solo la questione degli errori: 



http://goo.gl/5ALNi4




http://www.nikhef.nl/~dennisvd/lvmcrap.html








-- 

Massimiliano Adamo



in sostanza... 

zfs, btrfs: gli snapshot non impattano e li puoi mantenere (anche 48)

lvm2: ne usi uno per fare un backup e lo butti al più presto.  



-- 

Massimiliano Adamo



Sono "snapshot", non backup.



Quei due articolisti non hanno capito la differenza.



Ovviamente la tentazione di usare snapshot come

backup e` forte, ma LVM dichiara *esplicitamente*

che gli snapshot sono da considerarsi volatili.



E comunque, non e` solo una questione di snapshot,

come gia` scritto.

Anzi, quella e` solo una conseguenza di come funziona

il tutto.



Ed infine, come ripetuto piu` volte, usando quel

metodo (LVM) e` possibile usare un fs qualunque,

non si e` costretti ad uno particolare.



bye,



-- 



piergiorgio


 Sono "snapshot", non backup. 



Con LVM. Ma se usi un FS cow, volendo, puoi usare gli snapshot anche come 

rudimentale sistema di versioning. Molto rudimentale, ma giusto per fare 

capire che lo snapshot non impatta.  



-- 

Massimiliano Adamo


 capire che lo snapshot non impatta.  



Posso anche usare un RAID-1... :-)



Come gia` scritto, gli snapshot sono *solo*

una delle cose che si ha usando md+lvm.



Con md abbiamo RAID-1 ibridi (dischi lenti

e veloci), abbiamo RAID-10 integrati, per

sicurezza e prestazioni, abbiamo la possibilita`

di rimpiazzare un disco *senza* togliere

prima quello da rimpiazzare.

Varie ed eventuali.



Con LVM e` possibile aggiungere una cache

veloce, chesso` SSD, ad uno storage lento,

tipo RAID-6.

La cache puo` essere su due SSD in RAID-10, con

md, in modo da avere sicurezza e prestazioni

aggiuntive (in lettura).

LVM gestisce i thin pool, ma questo dovrebbero

farlo anche zfs/btrfs, credo.



E tutto questo possiamo averlo *senza* essere

schiavi di un singolo fs.

Per esempio, se ci serve un fs che abbia

prestazioni elevate con file relativamente

piccoli (mail server), possiamo creare il

sistema che piu` si adatta allo scopo, con

il fs specifico per quel requisito.



Quindi, ripeto, si md+lvm+fs e` meglio.



E` piu` sicuro, perche` i bug non sono correlati,

e` piu` flessibile, perche` ci consente di usare

i tool che piu` soddisfano i requisiti che ci

interessano, ha piu` feature.



E riguardo il RAID-1 iniziale, c'e` chi ha fatto,

con md, un RAID-1 ricorsivo, cioe` un RAID-1 fatto

da un disco e da un RAID-1, questo a sua volta

fatto da un disco e da un RAID-1, etc.



Questo sistema consente di gestire *backup* a

rotazione cambiando a turno i dischi dell'albero.



bye,



-- 



piergiorgio


 fornitori



Leggendo questa mi viene da pensare che ho travisato ciò che volevi dire,

ovvero che il problema in questo caso il fatto che dietro a ZFS ci sia solo

una figura. Se così fosse, allora il problema sarebbe molto più ampio, perché

anche ad esempio dietro a Python (che viene usato da molte distribuzioni per

l'installazione e la manutenzione del sistema) c'è una sola figura, e così per

molti altri software, non credi?



Enrico


 E Gnome segue a ruota.



Mah, quando usavo KDE (fino al 4, perché 5 è Una Merda™), usavo il browser che

mi pareva e i software che volevo senza che avessi troppi problemi anche nel

rimuovere quei software che non mi servivano (konqueror compreso). Certo, che

poi non lo facessi perché di solito era dell'ottimo software è un altro

discorso (seriamente, ancora oggi ho problemi a trovare un editor X decente che

possa soppiantare appieno kate) ;)



Enrico


 raid-z, striped arrays, mirror.... e non sono sperimentali. 



Diciamo che questo thread mi sta facendo vedere aspetti di LVM che mi fanno

andare sempre di più nella direzione di abbandonarlo in favore di ZFS... ;)



Enrico


 No, ci sara` su Ubuntu... :-)



No, ci sarà ANCHE su Ubuntu. Perché oltre al supporto ufficiale del progetto,

ci sono anche altre distribuzioni che lo usano ufficialmente (ti posso citare

solo Proxmox, però). Da questo punto di vista Canonical ha il solo pregio di

essere la prima tra i grandi a fare questo passo



Enrico


 Menti :) 



Non mente, Piergiorgio sta semplicemente sta dicendo che ha trovato corruzioni

del file system *derivate* da altri problemi, non da problemi del file system



Enrico


 che bisogna imparare 3 set di comandi.



Non è solo un discorso di tre set di comandi, è un discorso di come funziona il

tutto. Per capirci, ho notato 3 (tre) diversi comportamenti di mdadm su

distribuzioni differenti e sulla stessa distribuzione in base a come lo si

attiva (nel dettagli su CentOS, se crei un RAID dopo che hai installato il

sistema, per motivi che non sono riuscito a capire nel caso in cui ti si rompe

un disco al successivo riavvio il RAID viene ricreato come inattivo e quindi

inaccessibile se non tramite intervento manuale, cosa che non succede se il

RAID lo crei in fase di installazione o se stai usando un'altra distribuzione).

Con ZFS, ho lo stesso comportamento *sempre*, sia che mi trovo su Linux, sia

che mi trovo su FreeBSD (che poi in un passaggio cross os sia carino rifare il

partizionamento dei dischi, è un altro discorso che si potrebbe riassumere in

GPT merda)



Enrico


 rotazione cambiando a turno i dischi dell'albero.



Ho già sentito di gente che usa il RAID 1 per fare backup, ed ho vomitato.

Molto meglio un zfs send | zfs recv, non foss'altro per il fatto che lavora su

di uno snapshot



Enrico


 andare sempre di più nella direzione di abbandonarlo in favore di ZFS.



Cerca la presentazione "Interesting things you didn't know you could do 

with ZFS" di Allan Jude.



-- 

Andrea




 del file system



Se per voi "problema" è solo quando non riesco più a montare il FS allora 

non ci capiamo. 

Per me, trovare miriadi di file (difficilmennte riutilizzabili) dentro la 

lost+found è un problema nel filesystem. E questo succcede con un semplice 

kernel panic, un riavvio alla disperata e così via. 

In questo senso "mente". 



-- 

Massimiliano Adamo


 sopravvivenza:)



Mica solo, questo thread sta offrendo più crediti formativi di un master 

in filesystemologia applicata, io prendo appunti e ringrazio gli astanti