Docker info e chiarimenti
Salve lista, spero essere nel posto giusto. Premetto che non sono un "guru" anzi. ho una serenino con Debian 10 dove ho installato homeassistant tramite Docker. generalmente lo usa via ssh e non video avvisi. stamane ho staccato un monitor e mi trovo la seguente riga: debian login: crond 288: USER root pid 289 cmd /share/hdd_tools/scripts/main.sh > /proc/1/fd/1 2> /proc/1/fd/2 am che significa? Grazie
Re: eseguire software di un'architettura hardware diversa da quella del proprio sistema (ERA: Re: Ancora CIE e middleware)
On Tue, Oct 19, 2021 at 11:03:09PM +0200, Alessandro Rubini wrote: > > notably 64bit kernels often support running > > 32bit software (but most probably not the converse)" che non sembra > > escludere definitivamente > > Se il mondo non e` cambiato nel frattempo, mi sentirei di escluderlo. > Un eseguibile a 64 bit usa puntatori a 64 bit e vuole una memoria > virtuale a 64 bit (non ricordo quanti, ma piu` di 32). Se il kernel > e` a 32 bit, offre una memoria virtuale a 32. > > > "or a qemu-user instance is configured > > to act as an on-the-fly emulation layer, see QemuUserEmulation" > > Questo funziona come un gioiellino. Ma ovviamente il codice viene > interpretato (da qemu), non eseguito, quindi va piu` lento. Qemu e` > straordinariamente efficente (e` Fabrice Bellard, mica l'ultimo > pistola) ma comunque siamo circa 10x piu` lento del nativo. > > > La cosa è molto interessante e, ad avere tempo, sarebbe da sperimentare > > E' banale. Si prende un eseguibile arm e si esegue. E` uno dei primi > esempi che faccio ai miei studenti, partendo da PC per andare su > micretto. > > Certo, se e` un eseguibile "serio" occorrono anche le librerie dinamiche > dell'architettura eccetera. Io lo faccio vedere senza libreria, > implementando le 2 chiamate di sistema che mi servono (write e exit): > >laptopo% make hell-arm >arm-none-eabi-gcc-c -o syscalls-arm.o syscalls-arm.S >arm-none-eabi-gcc -Wall -static -ffreestanding -c -o hell.o hell.c >arm-none-eabi-ld -e main -o hell-arm syscalls-arm.o hell.o > >laptopo% ./hell-arm >Hello > >laptopo% file hell-arm >hell-arm: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), > statically linked, not stripped > >laptopo% uname -m >x86_64 > > Il trucco sta in binfmtmisc, che definisce interpreti per vari formati > di file, in base al contenuto del file (il "magic number"): > >laptopo% ls /proc/sys/fs/binfmt_misc/ >cli qemu-aarch64 qemu-mipsqemu-sh4 >jar qemu-alpha qemu-mipsel qemu-sh4eb >llvm-3.1.binfmt qemu-arm qemu-ppc qemu-sparc >python2.6qemu-armeb qemu-ppc64 qemu-sparc32plus >python2.7qemu-crisqemu-ppc64abi32 qemu-sparc64 >python3.2qemu-m68kqemu-ppc64le register >python3.4qemu-microblaze qemu-s390x status Alex al solito sei stellare, questa mail me la salvo... Si lo so, dirai, banale, ok ... per te, e una volta che l'ho letta, anche per me. È questo il punto: è tutto semplice _dopo_ che lo sai. GRAZIE -- Saluton, Marco Ciampa
Re: eseguire software di un'architettura hardware diversa da quella del proprio sistema (ERA: Re: Ancora CIE e middleware)
> notably 64bit kernels often support running > 32bit software (but most probably not the converse)" che non sembra > escludere definitivamente Se il mondo non e` cambiato nel frattempo, mi sentirei di escluderlo. Un eseguibile a 64 bit usa puntatori a 64 bit e vuole una memoria virtuale a 64 bit (non ricordo quanti, ma piu` di 32). Se il kernel e` a 32 bit, offre una memoria virtuale a 32. > "or a qemu-user instance is configured > to act as an on-the-fly emulation layer, see QemuUserEmulation" Questo funziona come un gioiellino. Ma ovviamente il codice viene interpretato (da qemu), non eseguito, quindi va piu` lento. Qemu e` straordinariamente efficente (e` Fabrice Bellard, mica l'ultimo pistola) ma comunque siamo circa 10x piu` lento del nativo. > La cosa è molto interessante e, ad avere tempo, sarebbe da sperimentare E' banale. Si prende un eseguibile arm e si esegue. E` uno dei primi esempi che faccio ai miei studenti, partendo da PC per andare su micretto. Certo, se e` un eseguibile "serio" occorrono anche le librerie dinamiche dell'architettura eccetera. Io lo faccio vedere senza libreria, implementando le 2 chiamate di sistema che mi servono (write e exit): laptopo% make hell-arm arm-none-eabi-gcc-c -o syscalls-arm.o syscalls-arm.S arm-none-eabi-gcc -Wall -static -ffreestanding -c -o hell.o hell.c arm-none-eabi-ld -e main -o hell-arm syscalls-arm.o hell.o laptopo% ./hell-arm Hello laptopo% file hell-arm hell-arm: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, not stripped laptopo% uname -m x86_64 Il trucco sta in binfmtmisc, che definisce interpreti per vari formati di file, in base al contenuto del file (il "magic number"): laptopo% ls /proc/sys/fs/binfmt_misc/ cli qemu-aarch64 qemu-mipsqemu-sh4 jar qemu-alpha qemu-mipsel qemu-sh4eb llvm-3.1.binfmt qemu-arm qemu-ppc qemu-sparc python2.6qemu-armeb qemu-ppc64 qemu-sparc32plus python2.7qemu-crisqemu-ppc64abi32 qemu-sparc64 python3.2qemu-m68kqemu-ppc64le register python3.4qemu-microblaze qemu-s390x status
Re: eseguire software di un'architettura hardware diversa da quella del proprio sistema (ERA: Re: Ancora CIE e middleware)
On 19/10/21 10:42, Diego Zuccato wrote: Il 18/10/2021 22:21, Davide Prina ha scritto: On 18/10/21 08:49, Diego Zuccato wrote: Ovviamente: un sistema a 64 bit può gestire una lib a 32 bit ma non viceversa. in teoria, con Debian, puoi creare un sistema a più architetture hardware e quindi avere un sistema 64-32 bit... e probabilmente lo puoi ottenere sia partendo da un sistema a 32 che da uno a 64 (ho provato solo da amd64 aggiungere i386) Si, puoi forse partire da uno a 32 bit, ma se il kernel non è a 64 bit, il processore girerà solo a 32. In pratica il processore in modalità 64 bit riconosce il codice a 32 bit e va in modalità compatibile (sto semplificando al massimo). Ma se il processore è in modalità 32 bit, non sa nulla del codice a 64 bit e se va bene si blocca su un illegal opcode. se devo essere sincero non ho mai approfondito più di tanto la questione di quale foreign architecture puoi installare sulla tua macchina e una volta fatto cosa effettivamente ci puoi fare. L'unica cosa che ho fatto è installare l'architettura i386 su un'architettura amd64. Però se si guarda il wiki di Debian relativo alla multiarchitettura[¹] prima indica con questa frase "either the kernel supports a compatibility interface, notably 64bit kernels often support running 32bit software (but most probably not the converse)" che non sembra escludere definitivamente questa possibilità, mentre io mi sarei aspettato, come hai indicato tu, una frase che escludesse categoricamente l'esecuzione di software a 64 bit su un'architettura hardware a 32 bit. Poi però offre una modalità per poter eseguire qualsiasi software di qualsiasi architettura hardware supportata da Debian sulla propria architettura hardware "nativa": "or a qemu-user instance is configured to act as an on-the-fly emulation layer, see QemuUserEmulation" che punta alla pagina di QemuUserEmulation[²] Da quello che ho capito, guardando rapidamente questa seconda pagina, sembra possibile installare software di una qualsiasi foreign architecture ed eseguirlo in modo trasparente, come se fosse dell'architettura "nativa". La cosa è molto interessante e, ad avere tempo, sarebbe da sperimentare Ciao Davide [¹] https://wiki.debian.org/Multiarch/HOWTO [²] https://wiki.debian.org/QemuUserEmulation -- Sistema operativo: http://www.debian.org GNU/Linux User: 302090: http://counter.li.org Non autorizzo la memorizzazione del mio indirizzo su outlook
Re: Filesystem con compressione
On Tue, Oct 19, 2021 at 12:08:05PM +0200, Alessadro Baggi wrote: > Ora vado un attimo off-topic: sulle distro rhel based ci sta anche il VDO e > i relativi tool. Ogni giorno se ne impara una nuova... ;-) > Praticamente aggiunge un layer per la compressione e deduplicazione. > La cosa che mi lascia un po perplesso è che un volume vdo > deve presentare una dimensione logica che il filesystem (xfs) va ad usare. > Quindi se un fs XFS risultasse usato al 100%, mentre sul volume magari siamo > al 30%, bisogna aumentare la logical size e fare un resize del filesystem > per fargli avere più spazio... Così funziona anche con LVM... > cosi bisogna monitorare sia il filesystem > classico sia il volume vdo. e anche LVM quindi sono tre... > Bo devo approfondire anche se ho visto che su > debian non c'è traccia di VDO. E quindi solo per curiosità... > Ovviamente VDO non è un fs con cow, con integrity, snapshot e varie. A me sembra cie VDO sia più una cosa per data-center... -- Saluton, Marco Ciampa
Re: Filesystem con compressione
Il 19/10/21 10:40, Bertorello, Marco ha scritto: Il 19/10/2021 10:32, Alessadro Baggi ha scritto: Il 19/10/21 10:27, Bertorello, Marco ha scritto: Il 19/10/2021 09:36, Alessadro Baggi ha scritto: Buongiorno a tutta la lista. Ho un piccolo server di backup con Debian 11 e 2 dischi da 3TB in raid1 con mdadm. Il backup lo faccio con uno script rsync. Stavo cercando dei filesystem che avessero la compressione trasparente e ho trovato btrfs e ZFS. Leggendo sui due, ho preso nota anche di tutte le altre caratteristiche come deduplicazione, checksumming e relativo recovery, snapshot, COW filesystem e varie. Leggendo su btrfs da qui [0] sono rimasto abbastanza sfiduciato dai molti problemi che presenta btrfs. ZFS d'altra parte (se non sbaglio si trova in contrib) è di tutt'altra pasta, funziona bene ma (al di fuori della licenza) il sistema deve compilare un modulo e ad ogni aggiornamento del kernel dkms .. Grazie a tutti in anticipo e per il tempo dedicato. [0] https://wiki.debian.org/Btrfs Non lo uso per macchine fisiche, ma so che sono supportate attraverso un agent, tuttavia mi sento di consigliarti questo: https://www.proxmox.com/en/proxmox-backup-server Puo' usare ZFS e, nel caso, farebbe sia compressione che deduplica. Io lo uso con molta soddisfazione fin dalle prime beta. Puo' anche essere usato per replicare i backup verso un altro PBS (io lo uso cosi' per il backup off-site via VPN e lo trovo davvero efficiente). Saluti, Ciao e grazie per la risposta. grazie per la risorsa. Tu hai avuto esperienze con ZFS? Si, lo uso sia su PBS che su PVE (soluzione di virtualizzazione di Proxmox) e non posso dirne che bene. Mi ha risolto diversi problemi con le sue feature: sostituisce il RAID, prevede l'utilizzo della cache (ad es. io lo uso con una partizione di un disco SSD come cache per 2 dischi meccanici nell'equivalente di un RAID0, la replica su altri host configurati in maniera identica mi mette al riparo dalla rottura di un disco e questo setup mi da le performance che mi servono), ha le repliche, gli snapshot ecc. L'unico caso in cui mi ha dato grattacapi e' quando sopra ho voluto metterci docker, ma magari (probabilmente) ho sbagliato qualcosa io :) Che problema ti ha dato con docker e come hai risolto? Hai mai avuto problemi con la ricompilazione con dkms con gli aggiornamenti del kernel? Su BTRFS purtroppo non ho mai avuto esperienze, ma mi sembra che sia una "bella promessa" da un po' troppo tempo ormai, senza mai essere adottato piu' di tanto. Ecco, hai centrato il punto, è tanto tempo che è in giro ma i principali problemi non sono ancora risolti...e andando avanti la cosa non migliora. Ciao, Grazie per la risposta.
Re: Filesystem con compressione
Il 19/10/21 10:46, Marco Ciampa ha scritto: On Tue, Oct 19, 2021 at 09:36:33AM +0200, Alessadro Baggi wrote: Buongiorno a tutta la lista. Ho un piccolo server di backup con Debian 11 e 2 dischi da 3TB in raid1 con mdadm. Il backup lo faccio con uno script rsync. Stavo cercando dei filesystem che avessero la compressione trasparente e ho trovato btrfs e ZFS. Leggendo sui due, ho preso nota anche di tutte le altre caratteristiche come deduplicazione, checksumming e relativo recovery, snapshot, COW filesystem e varie. Leggendo su btrfs da qui [0] sono rimasto abbastanza sfiduciato dai molti problemi che presenta btrfs. In particolare quale problema ti assilla? La perdita dei dati (anche se sono backup). Leggendo il wiki sembra non sia troppo affidabile, nel senso che ci sono talmente tante raccomandazioni che mi fa pensare di doverlo evitare. Ovviamente non l'ho mai usato come si deve ne per tempi prolungati quindi non posso giudicarlo realmente. ZFS d'altra parte (se non sbaglio si trova in contrib) è di tutt'altra pasta, funziona bene vedo che il marketing di Oracle funziona molto bene... sappi che btrfs è usato in ambito enterprise da aziende multinazionali. Se va bene per loro penso possa andare bene anche per te... Si, ho visto che btrfs è usato un bel po e si credo che vada bene per il mio utilizzo. Non credo che quelli di SUSE si siano bevuti il cervello usandolo come default. Sono in cerca di esperienze per non incappare in problemi catastrofici. In VM tutto va sempre bene poi quando lo si usa con dati veri iniziano le rogne. Leggendo su Reddit sembra che Oracle stia spingendo anche btrfs perche nella loro versione di EL hanno reintregrato il modulo e le util a differenza di rhel (e di centos, almalinux e rockylinux) che lo hanno completamente tagliato fuori (sia moduli che util). https://forum.armbian.com/topic/16285-why-i-prefer-zfs-over-btrfs/ il discorso che fa il tipo nella prima risposta, che non è un fan btrfs ma neanche zfs anche se usa il secondo, è molto onesto... grazie per la risorsa. ma (al di fuori della licenza) il sistema deve compilare un modulo e ad ogni aggiornamento del kernel dkms deve ricompilarlo e questo mi rende nervoso. Non vorrei che la compilazione con dkms fallisse e il filesystem non più accessibile. welcome to the reality... ZFS l'ho provato in macchina virtuale con volumi in raid1, e a primo sguardo sembra eccellente...l'unica cosa che mi lascia perplesso oltre a dkms è che durante l'installazione viene mostrato una specie di disclaimer dove si dice che si puo andare incontro a problemi legali per la licenza (sapete quali e in quali casi ci si va incontro?). Se non ricordo male Ubuntu lo utilizza e integra senza problemi. Ubuntu lo ha integrato non senza polemiche. Molti pensano che abbiano "interpretato" la licenza in modo "creativo". Ovvio(?) che Oracle non denuncerà mai Canonical ma non è questo il punto... qui siamo in Debian con una filosofia un "filino" diversa ... o no? Ora avendo poca esperienza con tutti e due, qualcuno ha avuto a che fare con questo tipo di filesystem? Avete incontrato particolari problemi? Ci sono alternative valide? Io uso da tempo btrfs sia direttamente con Debian che indirettamente (Synology). Ho letto di Synology e anche sul loro sito ne parlano. Ora vado un attimo off-topic: sulle distro rhel based ci sta anche il VDO e i relativi tool. Praticamente aggiunge un layer per la compressione e deduplicazione. La cosa che mi lascia un po perplesso è che un volume vdo deve presentare una dimensione logica che il filesystem (xfs) va ad usare. Quindi se un fs XFS risultasse usato al 100%, mentre sul volume magari siamo al 30%, bisogna aumentare la logical size e fare un resize del filesystem per fargli avere più spazio...cosi bisogna monitorare sia il filesystem classico sia il volume vdo. Bo devo approfondire anche se ho visto che su debian non c'è traccia di VDO. Ovviamente VDO non è un fs con cow, con integrity, snapshot e varie. Grazie per la risposta.
Re: Filesystem con compressione
On Tue, Oct 19, 2021 at 09:36:33AM +0200, Alessadro Baggi wrote: > Buongiorno a tutta la lista. > > Ho un piccolo server di backup con Debian 11 e 2 dischi da 3TB in raid1 con > mdadm. Il backup lo faccio con uno script rsync. Stavo cercando dei > filesystem che avessero la compressione trasparente e ho trovato btrfs e > ZFS. Leggendo sui due, ho preso nota anche di tutte le altre caratteristiche > come deduplicazione, checksumming e relativo recovery, snapshot, COW > filesystem e varie. > > Leggendo su btrfs da qui [0] sono rimasto abbastanza sfiduciato dai molti > problemi che presenta btrfs. In particolare quale problema ti assilla? > ZFS d'altra parte (se non sbaglio si trova in contrib) è di tutt'altra > pasta, funziona bene vedo che il marketing di Oracle funziona molto bene... sappi che btrfs è usato in ambito enterprise da aziende multinazionali. Se va bene per loro penso possa andare bene anche per te... https://forum.armbian.com/topic/16285-why-i-prefer-zfs-over-btrfs/ il discorso che fa il tipo nella prima risposta, che non è un fan btrfs ma neanche zfs anche se usa il secondo, è molto onesto... > ma (al di fuori della licenza) il sistema deve > compilare un modulo e ad ogni aggiornamento del kernel dkms deve > ricompilarlo e questo mi rende nervoso. Non vorrei che la compilazione con > dkms fallisse e il filesystem non più accessibile. welcome to the reality... > ZFS l'ho provato in > macchina virtuale con volumi in raid1, e a primo sguardo sembra > eccellente...l'unica cosa che mi lascia perplesso oltre a dkms è che durante > l'installazione viene mostrato una specie di disclaimer dove si dice che si > puo andare incontro a problemi legali per la licenza (sapete quali e in > quali casi ci si va incontro?). Se non ricordo male Ubuntu lo utilizza e > integra senza problemi. Ubuntu lo ha integrato non senza polemiche. Molti pensano che abbiano "interpretato" la licenza in modo "creativo". Ovvio(?) che Oracle non denuncerà mai Canonical ma non è questo il punto... qui siamo in Debian con una filosofia un "filino" diversa ... o no? > Ora avendo poca esperienza con tutti e due, qualcuno ha avuto a che fare con > questo tipo di filesystem? Avete incontrato particolari problemi? Ci sono > alternative valide? Io uso da tempo btrfs sia direttamente con Debian che indirettamente (Synology). -- Saluton, Marco Ciampa
Re: docker & c
Il 18-10-2021 20:11 Davide Prina ha scritto: non lo so e non so neanche cosa sia portainer. Però quando lo fai partire deve andare a leggere tale file e con il comando lsof, eseguito come root, puoi individuare cosa va a leggere # lsof | grep portainer conosco il comando lsof di solito i file di configurazione li trovi in posti tipo /etc/portrainer o in ~/.portrainer Portainer, è una gui per gestire docker, kubernetes, e suppongo possa gestire anche podman. Esso stesso si installa come container. Quindi non crea directory di configurazione al di fuori del container. Podman, lo avevo già sentito, ma sinceramente ancora non ci ho dato uno sguardo. Volevo partire da docker, per poi vedere anche podman. Mi farò un giro anche sul loro sito e lo proverò. Al momento però dovrò risolvere la grana portainer, perché mi son reso conto che effettivamente una gui per gestire "n" container, è decisamente più comoda che impazzire con tutti i parametri della shell, e non doverli ricordare. /paride -- http://keys.gnupg.net/pks/lookup?op=get&search=0xCC6CA35C690431D3 Chi e' pronto a rinunciare alle proprie liberta' fondamentali per comprarsi briciole di temporanea sicurezza non merita ne' la liberta' ne' la sicurezza.(Benjamin Franklin - dalla Risposta al Governatore, Assemblea della Pennsylvania, 11 novembre 1755)
Re: Ancora CIE e middleware
Il 18/10/2021 22:21, Davide Prina ha scritto: On 18/10/21 08:49, Diego Zuccato wrote: Ovviamente: un sistema a 64 bit può gestire una lib a 32 bit ma non viceversa. in teoria, con Debian, puoi creare un sistema a più architetture hardware e quindi avere un sistema 64-32 bit... e probabilmente lo puoi ottenere sia partendo da un sistema a 32 che da uno a 64 (ho provato solo da amd64 aggiungere i386) Si, puoi forse partire da uno a 32 bit, ma se il kernel non è a 64 bit, il processore girerà solo a 32. In pratica il processore in modalità 64 bit riconosce il codice a 32 bit e va in modalità compatibile (sto semplificando al massimo). Ma se il processore è in modalità 32 bit, non sa nulla del codice a 64 bit e se va bene si blocca su un illegal opcode. -- Diego Zuccato DIFA - Dip. di Fisica e Astronomia Servizi Informatici Alma Mater Studiorum - Università di Bologna V.le Berti-Pichat 6/2 - 40127 Bologna - Italy tel.: +39 051 20 95786
Re: Filesystem con compressione
Il 19/10/2021 10:32, Alessadro Baggi ha scritto: Il 19/10/21 10:27, Bertorello, Marco ha scritto: Il 19/10/2021 09:36, Alessadro Baggi ha scritto: Buongiorno a tutta la lista. Ho un piccolo server di backup con Debian 11 e 2 dischi da 3TB in raid1 con mdadm. Il backup lo faccio con uno script rsync. Stavo cercando dei filesystem che avessero la compressione trasparente e ho trovato btrfs e ZFS. Leggendo sui due, ho preso nota anche di tutte le altre caratteristiche come deduplicazione, checksumming e relativo recovery, snapshot, COW filesystem e varie. Leggendo su btrfs da qui [0] sono rimasto abbastanza sfiduciato dai molti problemi che presenta btrfs. ZFS d'altra parte (se non sbaglio si trova in contrib) è di tutt'altra pasta, funziona bene ma (al di fuori della licenza) il sistema deve compilare un modulo e ad ogni aggiornamento del kernel dkms .. Grazie a tutti in anticipo e per il tempo dedicato. [0] https://wiki.debian.org/Btrfs Non lo uso per macchine fisiche, ma so che sono supportate attraverso un agent, tuttavia mi sento di consigliarti questo: https://www.proxmox.com/en/proxmox-backup-server Puo' usare ZFS e, nel caso, farebbe sia compressione che deduplica. Io lo uso con molta soddisfazione fin dalle prime beta. Puo' anche essere usato per replicare i backup verso un altro PBS (io lo uso cosi' per il backup off-site via VPN e lo trovo davvero efficiente). Saluti, Ciao e grazie per la risposta. grazie per la risorsa. Tu hai avuto esperienze con ZFS? Si, lo uso sia su PBS che su PVE (soluzione di virtualizzazione di Proxmox) e non posso dirne che bene. Mi ha risolto diversi problemi con le sue feature: sostituisce il RAID, prevede l'utilizzo della cache (ad es. io lo uso con una partizione di un disco SSD come cache per 2 dischi meccanici nell'equivalente di un RAID0, la replica su altri host configurati in maniera identica mi mette al riparo dalla rottura di un disco e questo setup mi da le performance che mi servono), ha le repliche, gli snapshot ecc. L'unico caso in cui mi ha dato grattacapi e' quando sopra ho voluto metterci docker, ma magari (probabilmente) ho sbagliato qualcosa io :) Su BTRFS purtroppo non ho mai avuto esperienze, ma mi sembra che sia una "bella promessa" da un po' troppo tempo ormai, senza mai essere adottato piu' di tanto. Ciao, -- Marco Bertorello https://www.marcobertorello.it OpenPGP_0x5B7B17E82E9F51CE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Filesystem con compressione
Il 19/10/21 10:27, Bertorello, Marco ha scritto: Il 19/10/2021 09:36, Alessadro Baggi ha scritto: Buongiorno a tutta la lista. Ho un piccolo server di backup con Debian 11 e 2 dischi da 3TB in raid1 con mdadm. Il backup lo faccio con uno script rsync. Stavo cercando dei filesystem che avessero la compressione trasparente e ho trovato btrfs e ZFS. Leggendo sui due, ho preso nota anche di tutte le altre caratteristiche come deduplicazione, checksumming e relativo recovery, snapshot, COW filesystem e varie. Leggendo su btrfs da qui [0] sono rimasto abbastanza sfiduciato dai molti problemi che presenta btrfs. ZFS d'altra parte (se non sbaglio si trova in contrib) è di tutt'altra pasta, funziona bene ma (al di fuori della licenza) il sistema deve compilare un modulo e ad ogni aggiornamento del kernel dkms .. Grazie a tutti in anticipo e per il tempo dedicato. [0] https://wiki.debian.org/Btrfs Non lo uso per macchine fisiche, ma so che sono supportate attraverso un agent, tuttavia mi sento di consigliarti questo: https://www.proxmox.com/en/proxmox-backup-server Puo' usare ZFS e, nel caso, farebbe sia compressione che deduplica. Io lo uso con molta soddisfazione fin dalle prime beta. Puo' anche essere usato per replicare i backup verso un altro PBS (io lo uso cosi' per il backup off-site via VPN e lo trovo davvero efficiente). Saluti, Ciao e grazie per la risposta. grazie per la risorsa. Tu hai avuto esperienze con ZFS?
Re: Filesystem con compressione
Il 19/10/2021 09:36, Alessadro Baggi ha scritto: Buongiorno a tutta la lista. Ho un piccolo server di backup con Debian 11 e 2 dischi da 3TB in raid1 con mdadm. Il backup lo faccio con uno script rsync. Stavo cercando dei filesystem che avessero la compressione trasparente e ho trovato btrfs e ZFS. Leggendo sui due, ho preso nota anche di tutte le altre caratteristiche come deduplicazione, checksumming e relativo recovery, snapshot, COW filesystem e varie. Leggendo su btrfs da qui [0] sono rimasto abbastanza sfiduciato dai molti problemi che presenta btrfs. ZFS d'altra parte (se non sbaglio si trova in contrib) è di tutt'altra pasta, funziona bene ma (al di fuori della licenza) il sistema deve compilare un modulo e ad ogni aggiornamento del kernel dkms deve ricompilarlo e questo mi rende nervoso. Non vorrei che la compilazione con dkms fallisse e il filesystem non più accessibile. ZFS l'ho provato in macchina virtuale con volumi in raid1, e a primo sguardo sembra eccellente...l'unica cosa che mi lascia perplesso oltre a dkms è che durante l'installazione viene mostrato una specie di disclaimer dove si dice che si puo andare incontro a problemi legali per la licenza (sapete quali e in quali casi ci si va incontro?). Se non ricordo male Ubuntu lo utilizza e integra senza problemi. Ora avendo poca esperienza con tutti e due, qualcuno ha avuto a che fare con questo tipo di filesystem? Avete incontrato particolari problemi? Ci sono alternative valide? Grazie a tutti in anticipo e per il tempo dedicato. [0] https://wiki.debian.org/Btrfs Non lo uso per macchine fisiche, ma so che sono supportate attraverso un agent, tuttavia mi sento di consigliarti questo: https://www.proxmox.com/en/proxmox-backup-server Puo' usare ZFS e, nel caso, farebbe sia compressione che deduplica. Io lo uso con molta soddisfazione fin dalle prime beta. Puo' anche essere usato per replicare i backup verso un altro PBS (io lo uso cosi' per il backup off-site via VPN e lo trovo davvero efficiente). Saluti, -- Marco Bertorello https://www.marcobertorello.it OpenPGP_0x5B7B17E82E9F51CE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Filesystem con compressione
Buongiorno a tutta la lista. Ho un piccolo server di backup con Debian 11 e 2 dischi da 3TB in raid1 con mdadm. Il backup lo faccio con uno script rsync. Stavo cercando dei filesystem che avessero la compressione trasparente e ho trovato btrfs e ZFS. Leggendo sui due, ho preso nota anche di tutte le altre caratteristiche come deduplicazione, checksumming e relativo recovery, snapshot, COW filesystem e varie. Leggendo su btrfs da qui [0] sono rimasto abbastanza sfiduciato dai molti problemi che presenta btrfs. ZFS d'altra parte (se non sbaglio si trova in contrib) è di tutt'altra pasta, funziona bene ma (al di fuori della licenza) il sistema deve compilare un modulo e ad ogni aggiornamento del kernel dkms deve ricompilarlo e questo mi rende nervoso. Non vorrei che la compilazione con dkms fallisse e il filesystem non più accessibile. ZFS l'ho provato in macchina virtuale con volumi in raid1, e a primo sguardo sembra eccellente...l'unica cosa che mi lascia perplesso oltre a dkms è che durante l'installazione viene mostrato una specie di disclaimer dove si dice che si puo andare incontro a problemi legali per la licenza (sapete quali e in quali casi ci si va incontro?). Se non ricordo male Ubuntu lo utilizza e integra senza problemi. Ora avendo poca esperienza con tutti e due, qualcuno ha avuto a che fare con questo tipo di filesystem? Avete incontrato particolari problemi? Ci sono alternative valide? Grazie a tutti in anticipo e per il tempo dedicato. [0] https://wiki.debian.org/Btrfs