Oggi Petter Reinholdtsen sviluppatore del sistema operativo Debian ha informato la community circa la disponibilità del filesystem ZFS.

Per chi non lo sapesse ZFS è un file system open source sviluppato dalla Sun Microsystems per il suo sistema operativo Solaris. È stato progettato da un team con a capo Jeff Bonwick.. Il nome originario doveva essere “Zettabyte File System”, ma è diventato un acronimo.

debian

ZFS on Linux è l’implementazione ufficiale di OpenZFS per Linux, offre supporto nativo per ZFS su sistemi GNU/Linux, per ora le distro supportate sono Arch Linux, Ubuntu, Fedora, Gentoo, Red Hat Enterprise Linux, CentOS, openSUSE, e adesso anche Debian.

Come conferma l’annuncio di oggi gli utenti Debian possono ora installare dalla repo ufficiale zfs-linux 0.6.5.6-2 (versione instabile) oppure ZFS Linux 0.6.5.7 che è la versione stabile.

-“Oggi dopo anni di duro lavoro, ZFS è disponibile anche per Debian. Il package status potete trovarlo qui mentre qui trovate il codice sorgente.“- Questo è un sunto dell’annuncio da parte di Reinholdtsen .

Anche Canonical ha da poco introdotto il supporto completo a ZFS che infatti è incluso di default in Ubuntu 16.04 LTS (Xenial Xerus).

Se voleste provarlo non dimenticate di aiutare gli sviluppatori con il testing del pacchetto DKMS.

  • prokopios

    ZFS è un file system a 128 bit: può quindi fornire uno spazio di 16 miliardi di miliardi di volte la capacità dei file system a 64 bit. I limiti del ZFS sono concepiti per essere così ampi da non essere mai raggiunti in una qualunque operazione pratica. Bonwick ha affermato che “per riempire un file system a 128 bit non sarebbero bastati tutti i dischi della terra”. La meccanica quantistica impone alcuni limiti fondamentali sul calcolo computazionale e sulla capacità di memorizzazione di una qualsiasi unità fissa. In particolare è stato dimostrato che un chilo di materia confinata in un litro di spazio può effettuare al massimo 10 alla 51esima operazioni al secondo su al massimo 10 alla 31esima bit di informazioni. Un pool di storage a 128 bit completamente riempito dovrebbe contenere 21 alla 28esima blocchi (nibble) = 2 alla 137esima bytes = 2 alla 140esima bits; quindi lo spazio minimo richiesto dovrebbe essere (2 alla 140esima bit) / (10 alla 31esima bits/kg) = 136 miliardi di kg. Con il limite dei 10 alla 31esima bit/kg, l’intera massa di un computer dovrebbe essere sotto forma di energia pura. Secondo l’equazione E=mc2, l’energia residua dei 136 miliardi di kg è di 1,2×10 alla 28esima J. La massa dell’oceano è circa 1,4×10 alla 21esima kg. Occorrerebbero 4.000 J per aumentare la temperatura di 1 kg di acqua per 1 grado Celsius e circa 400.000 J per bollire 1 kg di acqua ghiacciata. La fase di vaporizzazione richiede altri 2 milioni di J/kg. L’energia richiesta per bollire l’oceano è circa 2,4×10 alla 6esta J/kg * 1,4×10 alla 21esima kg = 3,4×10 alla 27esima J. Quindi, riempire uno storage a 128 bit dovrebbe richiedere più energia che bollire gli oceani. (wikipedia)

    A parte qualche problemino di allineamento mnemonico degli zeri a gruppi di tre sui 10 alla 28ottesima, la domanda che sorge spontanea e`: con l-arrivo futuro di cpu a 128 bit + ZFS a 128 bit smetteranno di romperci gli zpools con continui cambi di architetture?

    • chi lo sa, comunque sia la storia di ZFS a 128bit, mi ricordo che all’università ce l’aveva detta il mio prof di sistemi operativi xD

      ma cpu arriveranno? ne siamo sicuri? ora come ora mi sembra che i 64bit, siano difficili da saturare, i limiti non sono così raggiungibili come lo erano nelle architetture a 32bit

      • arasi

        nel giro di 20 anni probabilmente si

      • Samael

        Il problema del passaggio a 128 bit non è che il 64 bit è difficile da saturare, ma che Intel è un cancro e la sua architettura x86 è un pessimo standard de facto che tutto ha fatto tranne che innovare.

        Tanto per dirne una, nel settore server high-end il 64 bit è in giro dai primi anni ’90.
        Solo su Intel è arrivato in netto ritardo, come del resto tutte le innovazioni tipo l’hotswapping.
        Digital UNIX, poi rinominato Tru64 UNIX da Compaq dopo che aveva fagocitato la DEC, era a 64 bit fin dalla sua nascita.

        All’epoca di spazio per innovare ce n’era tanto, e ZFS è stato progettato a 128 bit non in ottica Intel, ma proprio in ottica SPARC.

        Oggi purtroppo di senso non ce n’è più molto, perché Intel e la sua architettura spazzatura è diventata dominante anche lato server a causa dei costi bassi delle sue CPU.

        • gabriele tesio

          Quali altre architetture ci sono? Io conosco solo l’x86, ARM e PowerPC (PowerPC viene ancora usato? nel senso processori di nuova fabbricazione)

          • Samael

            PowerPC non viene più usato, perché l’architettura POWER ormai viene solo sfruttata sui server IBM con AIX.
            IBM pare che comunque abbia reso aperta la sua tecnologia, tanto che oggi esiste un progetto per usare CPU IBM POWER8 su Workstation: h t t p s : // w ww . raptorengineering . com/TALOS/prerelease . php
            Le ultime CPU PPC stavano nelle console e nei vecchi Mac, ma ormai sono state quasi tutte sostituite con CPU x86 per ridurre i costi di porting.

            All’epoca, comunque, di architetture ce n’erano tante.
            Digital UNIX girava sulla gloriosa DEC Alpha.
            IBM AIX girava e gira tuttora su IBM POWER.
            HP-UX girava su HP/PA-RISC e poi dopo su Intel-HP Itanium (IA-64, la vera architettura Intel a 64-bit).
            Sun Solaris girava principalmente su Sun SPARC.
            SGI IRIX girava su SGI MIPS.
            OpenVMS (il papà di Windows NT) prima su VAX e poi su Itanium.
            ecc.

            Più o meno ogni vendor UNIX aveva una sua architettura. E difatti tutte le workstation e server avevano hardware e sistema operativo completamente integrati.
            Le CPU venivano sviluppate pensando direttamente all’OS che doveva girarci, e l’OS veniva ottimizzato per la CPU target. Naturalmente essendo hardware e software ingegnerizzati dalla stessa azienda, i loro team lavoravano fianco a fianco.

          • Qfwfq

            ARM puo avere un futuro sui PC casalinghi e/o sui server?

          • Samael

            ARM è una famiglia di architetture RISC progettate non tanto per l’alta potenza di calcolo, quanto per il risparmio energetico.

            Per quanto riguarda i PC casalinghi: dobbiamo porci un’altra domanda. Ci saranno ancora?
            Onestamente il mercato PC è in costante declino da circa cinque anni ormai, soppiantato dagli smartphone che fanno praticamente qualsiasi cosa necessaria all’utenza domestica.

            I PC stanno per diventare mere workstation votate all’uso professionale, di sviluppo o gaming.
            E qui la vedo molto dura per ARM, non essendo ancora in grado di eguagliare Intel in termini di potenza bruta. E questo vale anche lato server.

            Senza contare che ARM si porta dietro anche un problema serio.
            Se hai notato bene, non ho scritto che ARM è un’architettura, ma una famiglia di architetture.
            Ebbene il problema di ARM è che l’architettura in sé non è definita totalmente, ma viene solo rilasciata parzialmente, in modo da lasciare al produttore di hardware il compito di implementare un SUO processore ARM con istruzioni anche specifiche. Questo fa sì che tutte le CPU ARM siano spesso diverse fra loro ed incompatibili.
            In sostanza ARM si pone tra un mondo fatto di architetture proprietarie come SPARC, POWER ecc. ed uno monoculturale con un’architettura de facto come Intel x86.
            Non a caso Torvalds si è lamentato tantissimo riguardo quest’architettura, alludendo all’avvelenare i progettisti. xD

            Ed è proprio la diversità di ARM il motivo per il quale Android usa Java e non può usare un qualcosa di pre-compilato e binario come fa iOS.
            Perché i binari compilati per una CPU ARM sono incompatibili con un’altra.
            Difatti, ART (che ha sostituito Dalvik) fa compilazione AOT: ovvero ogni app Android è in byte-code sull’app store e viene compilata in binario al momento dell’installazione sul dispositivo target.
            Alla base della scelta di Java non c’era solo il voler prendere sviluppatori dall’enorme bacino d’utenza del linguaggio.
            Ed è sempre per questi motivi che Google sta vagliando la migrazione a Swift. Perché quest’ultimo è progettato per girare con LLVM, che fornirebbe lo stesso livello di astrazione dalla piattaforma (bytecode) di Java.

            Ciò vuol dire che se ARM si diffondesse anche sul desktop, ci ritroveremmo con gli stessi problemi di Android sugli smartphone.

            Onestamente, io spero più nell’idea di Raptor Engineering, che tramite OpenPOWER (il progetto di IBM di aprire l’architettura POWER facendola diventare Open Hardware) potrebbe fornire una VERA alternativa ad Intel, con processori affidabili e qualitativamente superiori.
            Tra l’altro pare che persino Google abbia interessi e sia dentro il progetto OpenPOWER.

    • Caspita che dettaglio di informazioni scientifiche, mi sono sentito un ignorante completo. Scherzi a parte complimenti

      • gigilatrotttola

        Wikipedia

    • Samael

      A parte che le CPU a 128 bit è difficile che le vedrai non prima di 30 anni a partire da adesso, considerando quanto lenta è Intel ad evolvere. No ok, mi sono espresso male. Volevo dire: considerando quanto NON evolve Intel.

      Ma in ogni caso, dove starebbero questi “CONTINUI” cambi di architetture?
      A me risulta che l’unico “””cambio””” (se così si può definire) sono state le istruzioni EM64T/AMD64, che non sono state affatto un cambio di architettura in sé, visto che parliamo sempre di processori x86 che hanno in più il supporto allo spazio di indirizzamento a 64 bit.

      I cambi di architettura veri li hanno visti quelli che hanno lavorato con Workstation o server prodotti dai vendor storici di UNIX, che sono passati alle controparti Wintel.

      • gigilatrotttola

        vero su intel che non evolve, il 64bit è una creatura di AMD infatti

      • plasmad

        Se non ricordo male:
        8086 e 80286 erano a 16 bit
        IA-32 processori a 32 bit (80386 – Pentium 4)
        EM64T architettura a 64 bit con compatibilità IA-32 (eseguono codice a 64 bit e 32 bit)
        IA-64 architettura a 64 bit non compatibile con IA-32 (esegue solo codice a 64 bit)

        • Samael

          Sì, ma l’unica architettura differente lì è IA-64. Tutto il resto è x86. Non c’è stato alcun cambio di architettura.

          IA-32 in realtà non è che un altro nome con cui si identificano le CPU x86 con set di istruzioni a 32 bit.

          EM64T non è un’architettura, ma un set di istruzioni per processori a 32 bit.
          Tutti i processori Intel x86 si chiamano x86_64 perché sono 32 bit compatibili con lo spazio di indirizzamento a 64.
          In realtà nessuno di noi usa CPU a 64 bit sui desktop, perché le uniche Intel a 64 bit sono le CPU Itanium (IA-64).

          E le IA-64 non si trovano sui desktop, ma sui server HP. Ed il supporto su Windows è terminato con XP 64-bit Edition lato client e con Windows Server 2008 lato server.

          E comunque no, IA-64 può anche eseguire codice a 32 bit, ma la CPU lo fa tramite emulazione lato hardware.

  • gabriele tesio

    Che differenza c’è tra questa implementazione e quella di ubuntu di poche settimane fa?

    • Samael

      Quella di Canonical è binaria ed inclusa nel kernel.
      Questa è basata sul DKMS, quindi il modulo è in forma di sorgente e viene compilato al momento dell’installazione.

      • Alicia Frantinelli

        Anche quella di Ubuntu può essere basata su DKMS oltre che su fuse.

        • Samael

          La versione DKMS è una versione che deriva proprio dall’implementazione Debian che è stata messa in upstream adesso, in realtà.
          E no, l’altra non è basata su FUSE. ZFS-FUSE è un progetto morto anni e anni fa.
          Quella di Canonical è sempre nativa ed è basata sugli stessi sorgenti di quella Debian (cioè ZFSonLinux), ma con la differenza che è pre-compilata ed inclusa nel pacchetto linux-image. Che è poi il motivo per cui Canonical rischia i guai con la SFC.

      • Giacomo

        però non ho capito: anche con Debian posso installare l’intero sistema su ZFS, oppure soltanto partizioni aggiuntive rispetto a /boot e / ?

        • Samael

          Non so come funziona la live di debian.
          Se puoi uscire dall’installer ed accedere alla shell, allora dovresti poter installare zfs, compilandolo nella live, e poi installare una debian con debootstrap.

          Il punto però, Giacomo, è: ne vale la pena? Avendo già usato ZFS come root su una distro Linux ti dico subito di NO.
          ZFS come root non serve a niente, se non hai integrato un package manager che si prenda cura di creare cloni quando aggiorni componenti vitali dell’OS ed aggiungere una entry in GRUB per poterci fare il boot, come fa IPS su OpenSolaris e Solaris 11 sfruttando beadm.
          Tantovale usare BTRFS ed installare il plugin apt-btrfs-snapshot (o una cosa del genere) + Snapper (se supportato) che insieme fanno la stessa cosa.

          Per come la vedo io la configurazione migliore ottenibile su Linux è BTRFS per l’OS e ZFS per storage (ATTENZIONE: storage, non /home).

          • Giacomo

            scusa non ho potuto rispondere prima, anche se avevo letto. Molto chiaro il tuo punto di vista.
            Quindi un paio di altre domande:
            1) in ambito uso personale, su un disco esterno dedicato allo storage di foto, video e musica, quale tipo di partizione useresti? BTRFS o ZFS? fat 🙂 ? e come opereresti per un backup? (cp, rsync, sincronizzazione del fs?)
            2) in ambito lavorativo, per una condivisione di rete (condivisa con samba), dove ogni tanto gli utenti vogliono recuperare una vecchia versione del documento o un documento cancellato?

          • Samael

            1) ZFS e BTRFS sono utili per lo storage ma non ti salvano dall’hardware failure quando li usi su configurazioni single-disk.
            Se hai volumi grossi è meglio farsi un RAID, in modo da aggiungere ridondanza.
            Prendi due dischi di uguale dimensione e poi vai di ZFS.

            2) Decisamente ZFS, perché a differenza di BTRFS ha il supporto per case insensitive e mixed case, entrambi molto utili quando si deve condividere roba con Windows.
            Pensa che ZFS è anche indicato in ambiente misto UNIX-Windows per fare da backend al servizio di copie shadow di Windows, dove usi UNIX+ZFS per fare replica e copie shadow per recuperare i backup.

            Per quanto riguarda i back-up, scordati rsync che non serve a niente.
            Comprati un’altro HD di riserva, mettici ZFS/BTRFS e vai di zfs/btrfs send e recv.

  • help

    OT: Salve a tutti, con Firefox non riesco a visualizzare alcune pagine, come per esempio questo articolo (i commenti li vedo normalmente). Cercando su internet ho visto che per risolvere, bisognerebbe disattivare l’opzione “Allow pages to choose their own fonts, instead of my selections above”, ma ovviamente graficamente ci perderei molto, e a quel punto tanto varrebbe utilizzare Chrome o qualsiasi altro browser. C’è un modo per risolvere questo problema?

No more articles