Newsgroup: it.comp.os.linux.sys
Titolo: Jessie e root su ZFS

Visto che dovrò installare un server nuovo, voglio provare ad
usare ZFS.
 
Proxmox lo fa nativamente, ma questo server non sarà basato su proxmox ma Jessie.
ZFS è presente in Jessie tramite DKMS, ma senza che perdo 4 giorni googolando,
avete idea di come installare debian nativamente su ZFS ?
 
Da installer non mi pare sia possibile.
googolando ci sono mille-mila procedure diverse, se qualcuno ha voglia di
condividere la propria esperinza, mi risparmierebbe giorni di lavoro e di test.
 
Tnx.

 avete idea di come installare debian nativamente su ZFS ?
 
Questa è la guida ufficiale:
https://github.com/zfsonlinux/zfs/wiki/Debian%20Jessie%20Root%20on%20ZFS
 
 
Personalmente non l'ho mai fatto, anzi, sono passato a FreeBSD per avere una
root ZFS ;)
 
Enrico
P.S. in Jessie non dovrebbe essere un problema, ma tieni presente che potresti
trovarti in situazioni in cui il driver potrebbe non essere correttamente
allineato con il kernel, e quindi non compila, con esiti abbastanza drammatici

 usare ZFS.
 
Io aspetterei altri 8 anni(20 anni dal 2005)  prima di mettere in produzione zfs con debian,
attualmente non e' integrabile nel kernel quindi non avra mai un supporto "mainline" in debian.
Quindi o cambi distribuzione o eviterei di usarlo con debian che non ammette licensing non GPL.
 
D'altronde se usi una distribuzione e' perché alcune cose le fanno i mantainer , che senso ha
cominciare a pasticciare su cose cosi' delicate ? Diverso il discorso se stai "per tempo" cominciando
a testare il prodotto.
 
Giulia
 
 
 
 

 Io aspetterei altri 8 anni(20 anni dal 2005)
 
Per curiosità, perché si dovrebbe aspettare altri 8 anni?
 
Enrico

 a testare il prodotto.
 
Vero, sono d'accordo, concordo con te al 100%
 
Potrei però usare Ubuntu Server, li il supporto mi pare sia integrato nativamente.

 allineato con il kernel, e quindi non compila, con esiti abbastanza drammatici
 
Lo so. Ma "speravo" che il supporto DKMS presente in debian tramite contrib fosse comunque un minimo stabile.
 
Considera anche che il server in questione sarà un mailserver e che ho il brutto
vizio di evitare di aggiornare il kernel se non strettamente necessario, non dovrei
avere grossi problemi. ZFS si può spaccare solo in questi due casi:
 
a) aggiorno il kernel ed il modulo non è più compatibile
b) aggiorno il modulo ed il kernel è rimasto indietro
 
Ma considerato che ho server con uptime prossimi ai 7 anni........
 
Finchè non si rompe è inutile sistemarlo, questo mantra ha sempre funzionato.


Di solito i brevetti (e il relativo licensing) scadono 20 anni dopo la registrazione, siccome zfs e' del 2005
nel 2025 diventera di pubblico dominio.
 
Giulia
 
 

 Ma considerato che ho server con uptime prossimi ai 7 anni........
 
Brutta cosa, soprattutto per un mail server
 
Enrico

 nel 2025 diventera di pubblico dominio.
 
Ci sarebbe una soluzione molto, molto più semplice senza scomodare brevetti e licenza.
 
Se ZFS non si può integrare nel kernel, si può integrare il "kernel" in ZFS:
se gli sviluppatori del kernel portassero avanti attivamente anche ZFS come progetto parallelo,
basterebbe evitare di rilasciare il kernel finchè ZFS non compila correttamente
e viceversa non far avanzare ZFS senza il rispettivo update del kernel.
 
Se le persone coinvolte son le stesse, è più facile a farsi che a dirsi e non
sarebbe nemmeno la prima volta che due progetti vengano sviluppati in parallelo.
 
Dopotutto ZFS non è propriamente un mero progetto accademico, è probabilmente
il miglior filesystem presente oggigiorno e poterlo avere in forma stabile su 
Linux può solo far bene a tutti.

 Brutta cosa, soprattutto per un mail server
 
Mica vero. Io parlo del kernel, non dei servizi.
Di escalation da dovecot|exim fino arrivare al kernel non ne vedo più da parecchi anni.

 e viceversa non far avanzare ZFS senza il rispettivo update del kernel.
 
Non e` una questione di compilazione, e` una questione di
"uso del codice disponibile".
Il codice di ZFS, per via della licenza, non e` integrabile
nel kernel, cioe` non e` disponibile (per gli sviluppatori
del kernel, ovviamente).
Allora l'unica soluzione sarebbe *riscrivere* ZFS da zero,
con licenza compatibile, tipo GPL, nell'ipotesi che si possano
ignorare eventuali brevetti (perche` se vi sono brevetti, non
vi e` riscrittura che tenga).
 
Questa cosa e` stata fatta, si chiama btrfs.
 
Procede come procede, a dimostrazione che "soluzioni semplici"
non esistono.
 
bye,
 
-- 
 
piergiorgio

 parecchi anni.
Mica vengono corretti solo problemi di sicurezza.
Io controllo cosa è stato corretto e nel caso aggiorno.
 
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
 
www.robyt.eu
 
 

 non esistono.
 
Ma anche qui: perchè procede così a rilento ? Se ne parla da tipo 10 anni.
Non ho ancora capito se in questi 10 anni btrfs possa essere considerato stabile
per l'utilizzo su server con dati di produzione oppure no.
 
sembra che vi sia più interesse ad integrare il supporto di mille-mila driver
aggiuntivi (schede video, schede audio) bleeding-edge in ambito desktop piuttosto
che fixare, definitivamente, quelle 2-3 cose (fondamentali, a mio avviso) in ambito enterprise.
 
Son proprio l'ultimo a poter parlare di ZFS, fino a quale mese fa non ne ero 
nemmeno a conoscenza, ma dopo averlo provato (poco, ma è bastato) ed aver visto 
le features che offre, c'è poco da fare, è un filesystem rivoluzionario.
 
In fatto di poter fare sostanzialmente backup tramite snapshot+send+receive,
nativamente ed in forma incrementale, su server remoti, non ha prezzo.
Avere integrato, nativamente, in unico strumento: raid, autoreplace dei dischi, 
volumi con snapshot, backup, cache, anzichè usarne, ora come ora, almeno 5 di diversi
diversi (mdadm, script bash per il replace dei dischi, lvm, rsync, dmcache) non ha prezzo
 
P.S: btrfs è GPL ed è di Oracle. ZFS è di Sun, quindi sempre Oracle. 
Che cambino la licenza e non rompano i maroni! 
La stessa azienda che sviluppa un software come alternativa ad un altro proprio
software per questioni di licenza...... Follia pura.

 situazione non si verifica mai (di solito è 4.11-d1 -> 4.11-d2)
 
Spiega meglio.
E' chiaro che se cambio di major/minor, rischio di spaccare eventuali moduli extra.
Ma, AFAIK, su debian il passaggio da 4.11-d1 -> 4.11-d2 non è un cambio di major/minor ma un cambio di patch, con eventuali backport (d1, d2.....) di qualche fix importante senza obbligare l'upgrade di tutto il kernel.
Questo non dovrebbe rompere, se il cambio di patch è realmente un cambio di patch senza variare eventuali API interne.

 Io controllo cosa è stato corretto e nel caso aggiorno.
 
Si, anche io.
Ma l'unica componente che richiede il reboot (senza usare ksplice) è il kernel.
Ad oggi non ho ancora notato problematiche che mi abbiano obbligato ad un update in corsa.
 
e' chiaro che se ci fosse un bug che compromette la stabilità del sistema (mi è
capitato su alcuni server database), si aggiorna senza indugio. Ma se la macchina
è stabile da svariati anni, spesso è più pratico (almeno per me) sostituire
l'intera macchina spostando i dati. (che, con ZFS ed un volume ad-hoc solo per i
dati, si può fare facile-facile: send+receive e via andare, non aggiorni niente
e sposti tutto tra server)

 software per questioni di licenza...... Follia pura.
 
Come scritto sopra, evidentemente non gli interessa oppure
e` legalmente troppo problematico.
 
bye,
 
-- 
 
piergiorgio

 il team originale.
 
Che poi stando alla status page di btrfs, non siamo così tanto
lontani da avere un FS completo e stabile. Ci sono giusto 2 componenti
instabili e mi pare 3-4 in fase di testing.
 

 Basterebbe non ufficializzarlo.
 
Quello che vuoi tu si fa a livello di distribuzione patchando il kernel mainline,
quello che ti volgliamo dire e' che basta che non usi debian e sei a posto,
l'ostinazione ad usare debian (basta usare una debian derivata che implementi zfs se ti piace la pachettizzazione debian)
e' il tuo errore, non la coerenza all'interno del progetto 
kernel.org
 o debian.
 
Giulia
 
 

 e' il tuo errore, non la coerenza all'interno del progetto 
kernel.org
 o debian.
 
Non si tratta di ostinazione, ma bensì di uniformità con il resto dei sistemi
e di skills a livello di personale.
 
Se devi gestire il server casalingo, puoi passare a qualsivoglia distribuzione,
ma in azienda, dove ci sono turni e più persone che operano sui server, cambiare
distribuzione significa dover riskillare tutte le persone coinvolte.
 
Detto ciò, quali distribuzioni (linux) offrono ZFS integrato ? Mi pare nessuna.
E di conseguenza, quali distribuzioni derivate debian hanno ZFS?

 instabili e mi pare 3-4 in fase di testing.
 
Qualche release fa Fedora voleva usare btrfs
come FS ufficiale, ma poi non sono mai arrivati
ad avere una stabilita` sufficiente.
 
Non saprei quanto investimento vi sia dietro,
ma l'impressione e` che sia minore (sicuramente
almeno come PR) di ZFS.
 
bye,
 
-- 
 
piergiorgio

 Spiega meglio.
 
Fondamentalmente, io usavo ZFS su Fedora. Pertanto, una nuova release del
kernel te la ritrovi nell'ultimo rilascio della distribuzione. Per intenderci,
è come usare Debian testing, ma con uno "snapshot" semestrale. Ovviamente se
avessi usato CentOS questo non sarebbe accaduto, ma non si adattava ai miei
scopi (il mio è un server casalingo)
 
Enrico
P.S. per la cronaca, ora quel server è diventato un FreeBSD 11 ;)

 stabile per l'utilizzo su server con dati di produzione oppure no.
 
Qua ti rispondo io:
 
root@test:~# uname -a
Linux test 4.7.0-1-amd64 #1 SMP Debian 4.7.8-1 (2016-10-19) x86_64 GNU/Linux
root@test:~# mkfs.btrfs -d raid1 -m raid1 /dev/sdb1 /dev/sdc1
btrfs-progs v4.7.3
See 
http://btrfs.wiki.kernel.org
 for more information.
 
/dev/sdb1 appears to contain an existing filesystem (btrfs).
ERROR: use the -f option to force overwrite of /dev/sdb1
root@test:~# mkfs.btrfs -f -d raid1 -m raid1 /dev/sdb1 /dev/sdc1
btrfs-progs v4.7.3
See 
http://btrfs.wiki.kernel.org
 for more information.
 
Label:              (null)
UUID:
Node size:          16384
Sector size:        4096
Filesystem size:    40.00GiB
Block group profiles:
  Data:             RAID1             1.00GiB
  Metadata:         RAID1             1.00GiB
  System:           RAID1             8.00MiB
SSD detected:       no
Incompat features:  extref, skinny-metadata
Number of devices:  2
Devices:
   ID        SIZE  PATH
    1    20.00GiB  /dev/sdb1
    2    20.00GiB  /dev/sdc1
 
root@test:~# mount /dev/sdb1 /mnt/
root@test:~# df -h /dev/sdb1
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1        20G   17M   19G   1% /mnt
root@test:~# btrfs filesystem df -h /mnt
Data, RAID1: total=1.00GiB, used=512.00KiB
System, RAID1: total=8.00MiB, used=16.00KiB
Metadata, RAID1: total=1.00GiB, used=112.00KiB
GlobalReserve, single: total=16.00MiB, used=0.00B
root@test:~# shutdown -h now
[sgancio di /dev/sdc1 dalla vm e riavvio]
root@test:~# mount /dev/sdb1 /mnt/
mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
       missing codepage or helper program, or other error
 
       In some cases useful info is found in syslog - try
       dmesg | tail or so.
root@test:~# mount -o degraded /dev/sdb1 /mnt/
root@test:~#
 
Direi che questo basta per dire che no, btrfs non è (e non lo sarà mai) pronto
per la produzione
 
Enrico

 il team originale.
 
Quasi. Chris Mason (lo sviluppatore di Btrfs) ha lasciato Oracle nel 2012 per
andare in Fusion-IO anche con l'intento di continuare a sviluppare Btrfs. Per
quanto riguarda ZFS, il maggiore sviluppo fatto da Oracle (e che lo differisce
da OpenZFS) è stato l'inclusione dell'encryption
 
Enrico

 almeno come PR) di ZFS.
 
L'impressione che hai è sbagliata
 
Enrico

 L'impressione che hai è sbagliata
 
Non sarei del tutto sicuro e non sarei neanche sicuro
che la tua risposta sia piu` di un'impressione...
 
Lo stato delle cose non pone a favore di un particolare
interesse per btrfs, il che si puo` vedere semplicemente
come minore investimento.
 
RH stessa non pare credervi piu`...
 
bye,
 
-- 
 
piergiorgio

 RH stessa non pare credervi piu`...
 
Vi credono SUSE, Facebook e Intel:
https://btrfs.wiki.kernel.org/index.php/Contributors
 
 
Per inciso, i Synology propongono Btrfs come file system da utilizzare sul
pool di dischi installati
 
Enrico

 pool di dischi installati
 
Dubito fortemente, dato che BTRFS non supporta RAID[56] ed i synology si.
A meno che btrfs non sia un FS da poter usare *in aggiunta* al default.

 quello che ti volgliamo dire e' che basta che non usi debian e sei a posto,
 
Uhm, Ubuntu 16.04 LTS (comoda per i server) fornisce ZFS precompilato di default e disponibile come modulo.
 
Questo dovrebbe dare qualche tranquillità extra, dato che essendo fornito di default, si presume che venga anche compilato/allineato al kernel:
 
/lib/modules/4.4.0-59-generic/kernel/zfs/zfs/zfs.ko
 
e non l'ho messo io:
 
$ dpkg -l | grep -ic zfs
0

 pool di dischi installati
 
Non credo sia la prima opzione... :-)
 
bye,
 
-- 
 
piergiorgio

On 2017-01-17 00:45, Enrico Bianchi wrote:
[...]
 
Ho dimenticato un paio di cose.
 
Ovviamente, un FS in user space deve girare
con scheduler RT, per essere minimamente
confrontabile con l'equivalente kernel space.
Questo perche` il kernel e`, di fatto, RT.
 
Secondo, riguardo i FS in kernel.
Vi e` una certa politica secondo la quale
il kernel deve poter fare il boot con
qualunque FS.
Per poter far questo, il FS deve essere
in kernel (e magari non modulo, anche se
non e` proprio un requisito).
 
Ora, FS come ISOFS, UFS, VFAT sono tutti
ottimi candidati per user space, dato che
non necessitano di prestazioni particolari.
Pero` se il sistema deve poter partire con
questi FS, non si possono avere *solo* in
user space.
 
Di conseguenza, non ha senso sdoppiare i
FS in kernel (boot) e user (uso normale)
space, basta averli in kernel.
 
bye,
 
-- 
 
piergiorgio

 A meno che btrfs non sia un FS da poter usare *in aggiunta* al default.
 
Btrfs lo usi su di un block device, così come ZFS. Ed un block device può
esportelo anche mdadm
 
Enrico


Non supporta RAID[56]?
 
Strano, perche` qualche tempo fa parlavano del
fatto che dovrebbe (o potrebbe) usare il codice
di "md" per il RAID.
Tra l'altro e` stato esteso per piu` di due
dischi di parita` (RAID[78...]).
 
Ma forse e` ancora WIP.
 
bye,
 
-- 
 
piergiorgio

 Non ti sembra un po' troppo ricorsivo? :-)
 
Oracle e Fusion-IO sono la vecchia e la nuova azienda dove ha lavorato e lavora
il lead developer di Btrfs.
SUSE è la principale distribuzione che sponsonrizza e utilizza Btrfs.
Facebook ha dichiarato di utilizzare Btrfs sui propri server e di partecipare
al suo sviluppo.
STRATO AG (un ISP tedesco bello grosso) contribuisce al suo sviluppo.
Fujitsu contribuisce al suo sviluppo.
Intel contribuisce al suo sviluppo (per inciso, è stato scritto dai suoi
tecnici il codice per RAID5/6).
Netgear e Synology utilizzano Btrfs.
Red Hat ha contribuito al suo sviluppo.
 
No, direi che quella lista non sia troppo ricorsiva
 
Enrico


L'unico problema e' che l'installatore non supporta zfs (come una volta non supportava lvm2) quindi devi
fare alla vecchia maniera (live + debboostrap + tanta consolle)...
Anche grub2 dovrebbe supportare zfs.
 
Giulia
 

 Non supporta RAID[56]?
 
Btrfs supporta il RAID 5/6. Il problema però è che un pool che utilizza questa
modalità si corrompe come niente, pertanto è considerato instabile (per usare
un eufemismo)
 
Enrico

 Ma forse e` ancora WIP.
 
https://btrfs.wiki.kernel.org/index.php/RAID56
 

 Anche grub2 dovrebbe supportare zfs.
 
Come immaginavo, ma volevo proprio evitare l'installazione "vecchia maniera"
anche se poi il risultato sarebbe pressochè identico, dato che anche tramite
installer installo sempre il minimo del minimo (in pratica, poco più di un debootstrap)

 un eufemismo)
 
Esatto. quindi lo possiamo tranquillamente indicare come non supportato, dato che
loro stessi dicono di *NON* usarlo.
 
Ci sono quelle 2 features KO e 7 li-li per essere complete per poter considerare  btrfs eccezionale.
Chissà cosa diavolo aspettano, tutti quanti.
https://btrfs.wiki.kernel.org/index.php/Status
 
 
hai fatto un lungo elenco di big-player che sponsorizzano eppure la lista è
ferma da un po.
 
Ma btrfs, è attivamente sviluppato o lo stanno portando avanti nel tempo libero ?

 libero ?
 
Btrfs è attivamente sviluppato, per dire, gli ultimi commit sono di 10 giorni
fa. Avere una lista di pochi big player non significa che sia fermo
 
Enrico

 Avere una lista di pochi big player non significa che sia fermo
 
Non ho mai detto questo.
Semplicemente, considerati i nomi che girano, quelle 2-3 cose marcate in 'rosso'
potrebbero venire risolte in breve tempo rendendolo quantomeno stabile per l'uso
in produzione.

 per l'utilizzo su server con dati di produzione oppure no.
]zac[
 
Si e no.
 
Si se
- Non usi le funzionalita' raid di btrfs.
- Se e' accettabile il dovere ripristinare completamente il filesystem (in fase di test puo' capitare spesso, nel normale uso raramente).
- Se e' accettabile non avere tools di riparazione che diano garanzie di ripristinare il filesystem (in caso di corruzione dovuta a bug di btrfs le possibilita' sono piuttosto scarse, i tools di estrazione dati da un filesystem corrotto forse sono piu' affidabili).
- Se e' implementato un sistema di backup e ripristino totale e efficace.
 
No se
- Si vuole un'affidabilita' tipo quella di ext4 (per dare un paragone btrfs e' nel normale uso paragonabile a ext3, in caso di bug di btrs a ext2).
- Non e' accettabile un dowtime per il ripristino completo del filesystem.
- Non e' accettabile la minima perdita di dati.
 
In sintesi per uso privato o di non vitale importanza in produzione si puo' usare, per gli altri casi bisogna fare parecchi test altrimenti meglio evitare.
 
 
P.S. Per esempio, ho inziato a usare gli SSD come mio disco principale, e mi sono scritto uno script per l'invio degli snapshot (totali) di btrfs su altri due dischi rotativi e su un sistema remoto.
SSD + btrfs + sistema di snaphot, e' un sistema solido, e con basse probabilita di perdere dati, altrimenti non avrei usato ne btrs, ne SSD, troppe probabilita' di perdere dati.

 SSD + btrfs + sistema di snaphot, e' un sistema solido, e con basse probabilita di perdere dati, altrimenti non avrei usato ne btrs, ne SSD, troppe probabilita' di perdere dati.
 
Non sarei cosi catastrofico con gli SSD...

 Non sarei cosi catastrofico con gli SSD...
 
 
Sono convinto che, a parte la fascia bassa e medio bassa, ci siano SSD affidabili e con durata di 5-10 anni.
E' il loro modo di malfunzionare/guastarsi (totale) che li rende ''rischiosi''.
 
Per quanto mi riguarda solo con snapshot ''totali'' e frequenti considero l'uso degli SSD un rischio accettabile.
(Il mio utilizzo tipico e' fino a quando danno sintomi di malfunzionamento o prestazione al limite del sopportabile.)

 E' il loro modo di malfunzionare/guastarsi (totale) che li rende ''rischiosi''.
 
Descrivi bene a cosa ti riferisci....

 
https://redtowers.org/txt/va.a.capo.dopo.72.colonne.txt
 
 

 
https://redtowers.org/txt/va.a.capo.dopo.72.colonne.txt