• Filesystem con compressione

    From Alessadro Baggi@21:1/5 to All on Tue Oct 19 09:50:07 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bertorello, Marco@21:1/5 to All on Tue Oct 19 10:30:01 2021
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------S1Rrim0kgaVohE6rZg7etgJP
    Content-Type: multipart/mixed; boundary="------------8ofVqO50Je9PB40DwLNygU3O"

    --------------8ofVqO50Je9PB40DwLNygU3O
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

    DQpJbCAxOS8xMC8yMDIxIDA5OjM2LCBBbGVzc2Fkcm8gQmFnZ2kgaGEgc2NyaXR0bzoNCj4g QnVvbmdpb3JubyBhIHR1dHRhIGxhIGxpc3RhLg0KPg0KPiBIbyB1biBwaWNjb2xvIHNlcnZl ciBkaSBiYWNrdXAgY29uIERlYmlhbiAxMSBlIDIgZGlzY2hpIGRhIDNUQiBpbiANCj4gcmFp ZDEgY29uIG1kYWRtLiBJbCBiYWNrdXAgbG8gZmFjY2lvIGNvbiB1bm8gc2NyaXB0IHJzeW5j LiBTdGF2byANCj4gY2VyY2FuZG8gZGVpIGZpbGVzeXN0ZW0gY2hlIGF2ZXNzZXJvIGxhIGNv bXByZXNzaW9uZSB0cmFzcGFyZW50ZSBlIGhvIA0KPiB0cm92YXRvIGJ0cmZzIGUgWkZTLiBM ZWdnZW5kbyBzdWkgZHVlLCBobyBwcmVzbyBub3RhIGFuY2hlIGRpIHR1dHRlIGxlIA0KPiBh bHRyZSBjYXJhdHRlcmlzdGljaGUgY29tZSBkZWR1cGxpY2F6aW9uZSwgY2hlY2tzdW1taW5n IGUgcmVsYXRpdm8gDQo+IHJlY292ZXJ5LCBzbmFwc2hvdCwgQ09XIGZpbGVzeXN0ZW0gZSB2 YXJpZS4NCj4NCj4gTGVnZ2VuZG8gc3UgYnRyZnMgZGEgcXVpIFswXSBzb25vIHJpbWFzdG8g YWJiYXN0YW56YSBzZmlkdWNpYXRvIGRhaSANCj4gbW9sdGkgcHJvYmxlbWkgY2hlIHByZXNl bnRhIGJ0cmZzLg0KPg0KPiBaRlMgZCdhbHRyYSBwYXJ0ZSAoc2Ugbm9uIHNiYWdsaW8gc2kg dHJvdmEgaW4gY29udHJpYikgw6ggZGkgdHV0dCdhbHRyYSANCj4gcGFzdGEsIGZ1bnppb25h IGJlbmUgbWEgKGFsIGRpIGZ1b3JpIGRlbGxhIGxpY2VuemEpIGlsIHNpc3RlbWEgZGV2ZSAN Cj4gY29tcGlsYXJlIHVuIG1vZHVsbyBlIGFkIG9nbmkgYWdnaW9ybmFtZW50byBkZWwga2Vy bmVsIGRrbXMgZGV2ZSANCj4gcmljb21waWxhcmxvIGUgcXVlc3RvIG1pIHJlbmRlIG5lcnZv c28uIE5vbiB2b3JyZWkgY2hlIGxhIGNvbXBpbGF6aW9uZSANCj4gY29uIGRrbXMgZmFsbGlz c2UgZSBpbCBmaWxlc3lzdGVtIG5vbiBwacO5IGFjY2Vzc2liaWxlLiBaRlMgbCdobyANCj4g cHJvdmF0byBpbiBtYWNjaGluYSB2aXJ0dWFsZSBjb24gdm9sdW1pIGluIHJhaWQxLCBlIGEg cHJpbW8gc2d1YXJkbyANCj4gc2VtYnJhIGVjY2VsbGVudGUuLi5sJ3VuaWNhIGNvc2EgY2hl IG1pIGxhc2NpYSBwZXJwbGVzc28gb2x0cmUgYSBka21zIA0KPiDDqCBjaGUgZHVyYW50ZSBs J2luc3RhbGxhemlvbmUgdmllbmUgbW9zdHJhdG8gdW5hIHNwZWNpZSBkaSBkaXNjbGFpbWVy IA0KPiBkb3ZlIHNpIGRpY2UgY2hlIHNpIHB1byBhbmRhcmUgaW5jb250cm8gYSBwcm9ibGVt aSBsZWdhbGkgcGVyIGxhIA0KPiBsaWNlbnphIChzYXBldGUgcXVhbGkgZSBpbiBxdWFsaSBj YXNpIGNpIHNpIHZhIGluY29udHJvPykuIFNlIG5vbiANCj4gcmljb3JkbyBtYWxlIFVidW50 dSBsbyB1dGlsaXp6YSBlIGludGVncmEgc2VuemEgcHJvYmxlbWkuDQo+DQo+IE9yYSBhdmVu ZG8gcG9jYSBlc3BlcmllbnphIGNvbiB0dXR0aSBlIGR1ZSwgcXVhbGN1bm8gaGEgYXZ1dG8g YSBjaGUgDQo+IGZhcmUgY29uIHF1ZXN0byB0aXBvIGRpIGZpbGVzeXN0ZW0/IEF2ZXRlIGlu Y29udHJhdG8gcGFydGljb2xhcmkgDQo+IHByb2JsZW1pPyBDaSBzb25vIGFsdGVybmF0aXZl IHZhbGlkZT8NCj4NCj4gR3JhemllIGEgdHV0dGkgaW4gYW50aWNpcG8gZSBwZXIgaWwgdGVt cG8gZGVkaWNhdG8uDQo+DQo+DQo+IFswXcKgIGh0dHBzOi8vd2lraS5kZWJpYW4ub3JnL0J0 cmZzDQo+DQpOb24gbG8gdXNvIHBlciBtYWNjaGluZSBmaXNpY2hlLCBtYSBzbyBjaGUgc29u byBzdXBwb3J0YXRlIGF0dHJhdmVyc28gDQp1bsKgIGFnZW50LCB0dXR0YXZpYSBtaSBzZW50 byBkaSBjb25zaWdsaWFydGkgcXVlc3RvOg0KDQpodHRwczovL3d3dy5wcm94bW94LmNvbS9l bi9wcm94bW94LWJhY2t1cC1zZXJ2ZXINCg0KUHVvJyB1c2FyZSBaRlMgZSwgbmVsIGNhc28s IGZhcmViYmUgc2lhIGNvbXByZXNzaW9uZSBjaGUgZGVkdXBsaWNhLg0KDQpJbyBsbyB1c28g Y29uIG1vbHRhIHNvZGRpc2ZhemlvbmUgZmluIGRhbGxlIHByaW1lIGJldGEuIFB1bycgYW5j aGUgDQplc3NlcmUgdXNhdG8gcGVyIHJlcGxpY2FyZSBpIGJhY2t1cCB2ZXJzbyB1biBhbHRy byBQQlMgKGlvIGxvIHVzbyBjb3NpJyANCnBlciBpbCBiYWNrdXAgb2ZmLXNpdGUgdmlhIFZQ TiBlIGxvIHRyb3ZvIGRhdnZlcm8gZWZmaWNpZW50ZSkuDQoNClNhbHV0aSwNCg0KLS0gDQpN YXJjbyBCZXJ0b3JlbGxvDQpodHRwczovL3d3dy5tYXJjb2JlcnRvcmVsbG8uaXQNCg0K --------------8ofVqO50Je9PB40DwLNygU3O
    Content-Type: application/pgp-keys; name="OpenPGP_0x5B7B17E82E9F51CE.asc" Content-Disposition: attachment; filename="OpenPGP_0x5B7B17E82E9F51CE.asc" Content-Description: OpenPGP public key
    Content-Transfer-Encoding: quoted-printable

    -----BEGIN PGP PUBLIC KEY BLOCK-----

    xsBNBFzGyDgBCADI2Tcg5ZmbeFZFXYiBaoK3gVE8KUmTkkmktVjbCJaYTv0/NM/b3ryVcHOP0I5j wQKTtAO9AML78RWg5YSRkaJRa05WSBQ62QsewnPzdeXN4dLonlVY7t5pUswlMnRkKOe06QN6wNPQ Afkfz9mM9tjGpfE7bF3Es33psPQiS6Rpb5uJ/kKEvCvypBp2I0gQBjqZGV8gmJrPcjjx++6nhr6M v69D73K+eG3zjw8hxIZADZ2Su+vf8xmPXvwdQka4RwOgIcQnRuJ8IJtRCZpwf5R7S38XUNTWJJXn FwdvlwxYNxxjcMfsW8heyimrjh8NKkbi7Ivw0LetF/y1bukPC9oXABEBAAHNKE1hcmNvIEJlcnRv cmVsbG8gPG1lQG1hcmNvYmVydG9yZWxsby5pdD7CwI4EEwEIADgWIQSghRQa3M9ySYg42a5bexfo Lp9RzgUCXMbIOAIbIwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRBbexfoLp9RzooWCADDQ6Ao +pfdDNhCeMhEo3JJHuaDm2B5jiQb+yn1rzc6/4G1ELojE8tAYHaRinQH4d6gutiro2qiyE13uGtP 9IcLdihjxFyZi52xjOyG5FVEY8fCrzSZRJZWi/8sqdnxR3eTHshma4zFqCCfLiVY4TQF7WqFF5j+ ow+8xmRlvrg1eh411NxevtI0JB5nAyYT4ep/ziDAgAzXe+NzYmsDEJ0rX/yXehJ81MO+/og1z4bs U8g8AJM/ggTSv7506GVYbcKW92t/BhDZXk+9lHgtgUgHHSr9rPq3Suj9kr8U9V1kzL8ZeOudY0Rj IegyBAHurg3sNY792u0Pnt7htECXySYGzsBNBFzGyDgBCADYkJFUiXyKYlBNsFW+AnGPc7kZXEuE n88njntw457mgoQZCScBY+WPr3Pb3mmrGMA0D3kzY+JLAnuZbCcYPtaHgYaF40IlgGho7Sb/BZGv FhLCiX4OTckY8a6HPkHHFNPW1wJV2FoinKdOfrUvrNnUKpAosxh2JcpV48tSBpFMOgPB+vc/ePqh r7EqrY8asuhhKj0BjVT/z3LJTD41VbWuZ3/eNBMoaHzF2gxfkXWPrh5I7CVPId8Ot0cnyscnLx+T Qj4FycS3RAT3n4IcDUWI2P+I1Iyf0F7jK0mJd7BKXQb/tuvJ3Dl6oDhBU1oibtpuz22P53E6ggVg TWjPItApABEBAAHCwHYEGAEIACAWIQSghRQa3M9ySYg42a5bexfoLp9RzgUCXMbIOAIbDAAKCRBb exfoLp9RziZhCACcOCNv/qLl1JjkoX76oILYFnG5tzAS6d6EPM7rl/0eWtGABGBdSrvhLEw9btGG qOsSUyet05wiV5TidB8lbeFgtxlaL/13uWcWUYwTvhPUKilK2CTYW5oBI1AGlqFLGWI+CeRbxMMA 9Wxe5JsEvuc+WWB2TdHa8H7N7egKUEkdh8fBvDt87m0cCEOBfXMtY2yVBvUh9boOy0IfRQKN5xf1 gvcOZcPIMngq2/dAzpGbYvX65wohG6s8BzdxXbKy7Opdb00au+f55zSvF8u2U0cAFeiaZVYavcXD bWgEFavGQAflplzGyi02cG3fPJiMe6vI72AvA8a4GlcIO3N5stCQ
    =d5vC
    -----END PGP PUBLIC KEY BLOCK-----
    --------------8ofVqO50Je9PB40DwLNygU3O--


    --------------S1Rrim0kgaVohE6rZg7etgJP--

    -----BEGIN PGP SIGNATURE-----

    wsB5BAABCAAjFiEEoIUUGtzPckmIONmuW3sX6C6fUc4FAmFugWAFAwAAAAAACgkQW3sX6C6fUc4c uQf/T5tRLmo9x9pwgBIZlXXydmsT5RQY3RfrZFOkumSn2BdnfyWO+n5LqK0+2gg010BNrUVV0vki jL1zqD5GUvBibqsVwGXKG7z48ozLoypBdGJ9wNnbEFYd2MA6pODHVrh6ZeQscpEbcIWhJ+FuTCHu AO3El3L4LXZyIxiEjgwTSDMqDltdRzyLmNGrOlibeMx9HiXvhRwJ/VTqVtFfGwRE/MgYfCZIfEBK /CfsHfKCiCY2aKtan3BHfWMY+L6Cu7o6Iy2I/hCrX7KI4Wd++nxAtrQhIArhfrl60WbuAPwNQass OX0IAhHqDUBV5zF71onWA6PW1RmBHD6+d45tJ0wxGA==
    =k9cH
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco Ciampa@21:1/5 to Alessadro Baggi on Tue Oct 19 10:50:01 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Alessadro Baggi@21:1/5 to All on Tue Oct 19 10:40:02 2021
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bertorello, Marco@21:1/5 to All on Tue Oct 19 10:50:01 2021
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------t3laDOIGRuzTv3y1e0XSnX7b
    Content-Type: multipart/mixed; boundary="------------rpaen9n1smC1XJQ7MBFYVnC0"

    --------------rpaen9n1smC1XJQ7MBFYVnC0
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

    DQpJbCAxOS8xMC8yMDIxIDEwOjMyLCBBbGVzc2Fkcm8gQmFnZ2kgaGEgc2NyaXR0bzoNCj4N Cj4gSWwgMTkvMTAvMjEgMTA6MjcsIEJlcnRvcmVsbG8sIE1hcmNvIGhhIHNjcml0dG86DQo+ Pg0KPj4gSWwgMTkvMTAvMjAyMSAwOTozNiwgQWxlc3NhZHJvIEJhZ2dpIGhhIHNjcml0dG86 DQo+Pj4gQnVvbmdpb3JubyBhIHR1dHRhIGxhIGxpc3RhLg0KPj4+DQo+Pj4gSG8gdW4gcGlj Y29sbyBzZXJ2ZXIgZGkgYmFja3VwIGNvbiBEZWJpYW4gMTEgZSAyIGRpc2NoaSBkYSAzVEIg aW4gDQo+Pj4gcmFpZDEgY29uIG1kYWRtLiBJbCBiYWNrdXAgbG8gZmFjY2lvIGNvbiB1bm8g c2NyaXB0IHJzeW5jLiBTdGF2byANCj4+PiBjZXJjYW5kbyBkZWkgZmlsZXN5c3RlbSBjaGUg YXZlc3Nlcm8gbGEgY29tcHJlc3Npb25lIHRyYXNwYXJlbnRlIGUgDQo+Pj4gaG8gdHJvdmF0 byBidHJmcyBlIFpGUy4gTGVnZ2VuZG8gc3VpIGR1ZSwgaG8gcHJlc28gbm90YSBhbmNoZSBk aSANCj4+PiB0dXR0ZSBsZSBhbHRyZSBjYXJhdHRlcmlzdGljaGUgY29tZSBkZWR1cGxpY2F6 aW9uZSwgY2hlY2tzdW1taW5nIGUgDQo+Pj4gcmVsYXRpdm8gcmVjb3ZlcnksIHNuYXBzaG90 LCBDT1cgZmlsZXN5c3RlbSBlIHZhcmllLg0KPj4+DQo+Pj4gTGVnZ2VuZG8gc3UgYnRyZnMg ZGEgcXVpIFswXSBzb25vIHJpbWFzdG8gYWJiYXN0YW56YSBzZmlkdWNpYXRvIGRhaSANCj4+ PiBtb2x0aSBwcm9ibGVtaSBjaGUgcHJlc2VudGEgYnRyZnMuDQo+Pj4NCj4+PiBaRlMgZCdh bHRyYSBwYXJ0ZSAoc2Ugbm9uIHNiYWdsaW8gc2kgdHJvdmEgaW4gY29udHJpYikgw6ggZGkg DQo+Pj4gdHV0dCdhbHRyYSBwYXN0YSwgZnVuemlvbmEgYmVuZSBtYSAoYWwgZGkgZnVvcmkg ZGVsbGEgbGljZW56YSkgaWwgDQo+Pj4gc2lzdGVtYSBkZXZlIGNvbXBpbGFyZSB1biBtb2R1 bG8gZSBhZCBvZ25pIGFnZ2lvcm5hbWVudG8gZGVsIGtlcm5lbCANCj4+PiBka21zIC4uLi4u Li4uLi4NCj4+PiBHcmF6aWUgYSB0dXR0aSBpbiBhbnRpY2lwbyBlIHBlciBpbCB0ZW1wbyBk ZWRpY2F0by4NCj4+Pg0KPj4+DQo+Pj4gWzBdwqAgaHR0cHM6Ly93aWtpLmRlYmlhbi5vcmcv QnRyZnMNCj4+Pg0KPj4gTm9uIGxvIHVzbyBwZXIgbWFjY2hpbmUgZmlzaWNoZSwgbWEgc28g Y2hlIHNvbm8gc3VwcG9ydGF0ZSBhdHRyYXZlcnNvIA0KPj4gdW7CoCBhZ2VudCwgdHV0dGF2 aWEgbWkgc2VudG8gZGkgY29uc2lnbGlhcnRpIHF1ZXN0bzoNCj4+DQo+PiBodHRwczovL3d3 dy5wcm94bW94LmNvbS9lbi9wcm94bW94LWJhY2t1cC1zZXJ2ZXINCj4+DQo+PiBQdW8nIHVz YXJlIFpGUyBlLCBuZWwgY2FzbywgZmFyZWJiZSBzaWEgY29tcHJlc3Npb25lIGNoZSBkZWR1 cGxpY2EuDQo+Pg0KPj4gSW8gbG8gdXNvIGNvbiBtb2x0YSBzb2RkaXNmYXppb25lIGZpbiBk YWxsZSBwcmltZSBiZXRhLiBQdW8nIGFuY2hlIA0KPj4gZXNzZXJlIHVzYXRvIHBlciByZXBs aWNhcmUgaSBiYWNrdXAgdmVyc28gdW4gYWx0cm8gUEJTIChpbyBsbyB1c28gDQo+PiBjb3Np JyBwZXIgaWwgYmFja3VwIG9mZi1zaXRlIHZpYSBWUE4gZSBsbyB0cm92byBkYXZ2ZXJvIGVm ZmljaWVudGUpLg0KPj4NCj4+IFNhbHV0aSwNCj4+DQo+IENpYW8gZSBncmF6aWUgcGVyIGxh IHJpc3Bvc3RhLg0KPg0KPiBncmF6aWUgcGVyIGxhIHJpc29yc2EuIFR1IGhhaSBhdnV0byBl c3BlcmllbnplIGNvbiBaRlM/DQo+DQpTaSwgbG8gdXNvIHNpYSBzdSBQQlMgY2hlIHN1IFBW RSAoc29sdXppb25lIGRpIHZpcnR1YWxpenphemlvbmUgZGkgDQpQcm94bW94KSBlIG5vbiBw b3NzbyBkaXJuZSBjaGUgYmVuZS4gTWkgaGEgcmlzb2x0byBkaXZlcnNpIHByb2JsZW1pIGNv biANCmxlIHN1ZSBmZWF0dXJlOiBzb3N0aXR1aXNjZSBpbCBSQUlELCBwcmV2ZWRlIGwndXRp bGl6em8gZGVsbGEgY2FjaGUgKGFkIA0KZXMuIGlvIGxvIHVzbyBjb24gdW5hIHBhcnRpemlv bmUgZGkgdW4gZGlzY28gU1NEIGNvbWUgY2FjaGUgcGVyIDIgZGlzY2hpIA0KbWVjY2FuaWNp IG5lbGwnZXF1aXZhbGVudGUgZGkgdW4gUkFJRDAsIGxhIHJlcGxpY2Egc3UgYWx0cmkgaG9z dCANCmNvbmZpZ3VyYXRpIGluIG1hbmllcmEgaWRlbnRpY2EgbWkgbWV0dGUgYWwgcmlwYXJv IGRhbGxhIHJvdHR1cmEgZGkgdW4gDQpkaXNjbyBlIHF1ZXN0byBzZXR1cCBtaSBkYSBsZSBw ZXJmb3JtYW5jZSBjaGUgbWkgc2Vydm9ubyksIGhhIGxlIA0KcmVwbGljaGUsIGdsaSBzbmFw c2hvdCBlY2MuDQoNCkwndW5pY28gY2FzbyBpbiBjdWkgbWkgaGEgZGF0byBncmF0dGFjYXBp IGUnIHF1YW5kbyBzb3ByYSBobyB2b2x1dG8gDQptZXR0ZXJjaSBkb2NrZXIsIG1hIG1hZ2Fy aSAocHJvYmFiaWxtZW50ZSkgaG8gc2JhZ2xpYXRvIHF1YWxjb3NhIGlvIDopDQoNClN1IEJU UkZTIHB1cnRyb3BwbyBub24gaG8gbWFpIGF2dXRvIGVzcGVyaWVuemUsIG1hIG1pIHNlbWJy YSBjaGUgc2lhIHVuYSANCiJiZWxsYSBwcm9tZXNzYSIgZGEgdW4gcG8nIHRyb3BwbyB0ZW1w byBvcm1haSwgc2VuemEgbWFpIGVzc2VyZSBhZG90dGF0byANCnBpdScgZGkgdGFudG8uDQoN CkNpYW8sDQoNCi0tIA0KTWFyY28gQmVydG9yZWxsbw0KaHR0cHM6Ly93d3cubWFyY29iZXJ0 b3JlbGxvLml0DQoNCg0K
    --------------rpaen9n1smC1XJQ7MBFYVnC0
    Content-Type: application/pgp-keys; name="OpenPGP_0x5B7B17E82E9F51CE.asc" Content-Disposition: attachment; filename="OpenPGP_0x5B7B17E82E9F51CE.asc" Content-Description: OpenPGP public key
    Content-Transfer-Encoding: quoted-printable

    -----BEGIN PGP PUBLIC KEY BLOCK-----

    xsBNBFzGyDgBCADI2Tcg5ZmbeFZFXYiBaoK3gVE8KUmTkkmktVjbCJaYTv0/NM/b3ryVcHOP0I5j wQKTtAO9AML78RWg5YSRkaJRa05WSBQ62QsewnPzdeXN4dLonlVY7t5pUswlMnRkKOe06QN6wNPQ Afkfz9mM9tjGpfE7bF3Es33psPQiS6Rpb5uJ/kKEvCvypBp2I0gQBjqZGV8gmJrPcjjx++6nhr6M v69D73K+eG3zjw8hxIZADZ2Su+vf8xmPXvwdQka4RwOgIcQnRuJ8IJtRCZpwf5R7S38XUNTWJJXn FwdvlwxYNxxjcMfsW8heyimrjh8NKkbi7Ivw0LetF/y1bukPC9oXABEBAAHNKE1hcmNvIEJlcnRv cmVsbG8gPG1lQG1hcmNvYmVydG9yZWxsby5pdD7CwI4EEwEIADgWIQSghRQa3M9ySYg42a5bexfo Lp9RzgUCXMbIOAIbIwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRBbexfoLp9RzooWCADDQ6Ao +pfdDNhCeMhEo3JJHuaDm2B5jiQb+yn1rzc6/4G1ELojE8tAYHaRinQH4d6gutiro2qiyE13uGtP 9IcLdihjxFyZi52xjOyG5FVEY8fCrzSZRJZWi/8sqdnxR3eTHshma4zFqCCfLiVY4TQF7WqFF5j+ ow+8xmRlvrg1eh411NxevtI0JB5nAyYT4ep/ziDAgAzXe+NzYmsDEJ0rX/yXehJ81MO+/og1z4bs U8g8AJM/ggTSv7506GVYbcKW92t/BhDZXk+9lHgtgUgHHSr9rPq3Suj9kr8U9V1kzL8ZeOudY0Rj IegyBAHurg3sNY792u0Pnt7htECXySYGzsBNBFzGyDgBCADYkJFUiXyKYlBNsFW+AnGPc7kZXEuE n88njntw457mgoQZCScBY+WPr3Pb3mmrGMA0D3kzY+JLAnuZbCcYPtaHgYaF40IlgGho7Sb/BZGv FhLCiX4OTckY8a6HPkHHFNPW1wJV2FoinKdOfrUvrNnUKpAosxh2JcpV48tSBpFMOgPB+vc/ePqh r7EqrY8asuhhKj0BjVT/z3LJTD41VbWuZ3/eNBMoaHzF2gxfkXWPrh5I7CVPId8Ot0cnyscnLx+T Qj4FycS3RAT3n4IcDUWI2P+I1Iyf0F7jK0mJd7BKXQb/tuvJ3Dl6oDhBU1oibtpuz22P53E6ggVg TWjPItApABEBAAHCwHYEGAEIACAWIQSghRQa3M9ySYg42a5bexfoLp9RzgUCXMbIOAIbDAAKCRBb exfoLp9RziZhCACcOCNv/qLl1JjkoX76oILYFnG5tzAS6d6EPM7rl/0eWtGABGBdSrvhLEw9btGG qOsSUyet05wiV5TidB8lbeFgtxlaL/13uWcWUYwTvhPUKilK2CTYW5oBI1AGlqFLGWI+CeRbxMMA 9Wxe5JsEvuc+WWB2TdHa8H7N7egKUEkdh8fBvDt87m0cCEOBfXMtY2yVBvUh9boOy0IfRQKN5xf1 gvcOZcPIMngq2/dAzpGbYvX65wohG6s8BzdxXbKy7Opdb00au+f55zSvF8u2U0cAFeiaZVYavcXD bWgEFavGQAflplzGyi02cG3fPJiMe6vI72AvA8a4GlcIO3N5stCQ
    =d5vC
    -----END PGP PUBLIC KEY BLOCK-----
    --------------rpaen9n1smC1XJQ7MBFYVnC0--


    --------------t3laDOIGRuzTv3y1e0XSnX7b--

    -----BEGIN PGP SIGNATURE-----

    wsB5BAABCAAjFiEEoIUUGtzPckmIONmuW3sX6C6fUc4FAmFuhIQFAwAAAAAACgkQW3sX6C6fUc5v 9QgAhxSti9KXqp7jEI3Dh9fEWMVWesQix1IMeDP97F5r+Av8O9lRW3fq775dKl1MuxM5whtbiR5p e0HlZfF67cykknoypAgp3QZFqUiUSjpdYDb130IMNAG/l6x77dLfa+98xKoAArBysaQh/1BKJMbq BKazXOz3R1piQT0fTiYPq1xawtoVi6twrLnxmCmzAmrU2coCaHfw1a/vdNAB0xh3y+Tzr0SwHlTX 9TPNXzZWFoAo39Lx3fWtcIB2EaePDD/yRwMPbTHe/HQJy+UmQ9iFNtMk6x7ddjQ3799eyChFbKcB yIJJQ3X14OEafgvpvj9d+zWvt+3p61pnw7oIkcBkpA==
    =pfQg
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Alessadro Baggi@21:1/5 to All on Tue Oct 19 12:10:02 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Alessadro Baggi@21:1/5 to All on Tue Oct 19 12:20:02 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco Ciampa@21:1/5 to Alessadro Baggi on Tue Oct 19 15:20:02 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bertorello, Marco@21:1/5 to All on Wed Oct 20 11:00:02 2021
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------xJvGy7OOt0kqXdS179YCXJxE
    Content-Type: multipart/mixed; boundary="------------wCZvfUohtZr9O0NxzBe4gRy0"

    --------------wCZvfUohtZr9O0NxzBe4gRy0
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

    DQpJbCAxOS8xMC8yMDIxIDEyOjE0LCBBbGVzc2Fkcm8gQmFnZ2kgaGEgc2NyaXR0bzoNCj4g Q2hlIHByb2JsZW1hIHRpIGhhIGRhdG8gY29uIGRvY2tlciBlIGNvbWUgaGFpIHJpc29sdG8/ DQoNCk1haCwgY2VyY2F2byBkaSBmYXJlIHVuYSBjb3NhIHN0cmFuYSwgY2lvZScgZmFyIGdp cmFyZSBkb2NrZXIgDQooYXBwbGljYXRpb24gY29udGFpbmVyKSBjb24gdW4gb3JjaGVzdHJh dG9yZSAoY29tcG9zZSBvIHN3YXJtKSBkZW50cm8gDQpjb250YWluZXIgTFhDIChzeXN0ZW0g Y29udGFpbmVyKSwgY2hlIGdpYScgZGkgc3VvIG5vbiBlJyBzdXBwb3J0YXRvLCBjaSANCnZ1 b2xlIHF1YWxjaGUgdHJ1Y2NoZXR0by4NCg0KRmluY2hlJyBzaSB0cmF0dGF2YSBkaSBkb2Nr ZXIgZSBiYXN0YSBzZW1icmF2YSBhbmNoZSBmdW56aW9uYXJlLCBtYSBjb24gDQp1biBvcmNo ZXN0cmF0b3JlLCBub24gYydlcmEgdmVyc28gY2hlIGNvbnRhaW5lciBkaSB1bm8gc3Rlc3Nv IHN0YWNrIHNpIA0KcGFybGFzc2Vyby4NCkhvIGltcHV0YXRvIGxhIGNvc2EgYSBaRlMsIHZp c3RvIGNoZSBobyB0cm92YXRvIG1vbHRlIGd1aWRlIGNoZSANCnBhcmxhdmFubyBkaSBxdWVz dG8gc2V0dXAsIG1hIGRpY2V2YW5vIGNoZSBkb2NrZXIgc2kgImFjY29yZ2UiIGNoZSBzb3R0 byANCmMnZScgWkZTLg0KDQpQb2kgcmlwZXRvLCBtYWdhcmkgKHByb2JhYmlsbWVudGUpIGhv IHNiYWdsaWF0byBxdWFsY29zYSBpby4NCg0KPg0KPiBIYWkgbWFpIGF2dXRvIHByb2JsZW1p IGNvbiBsYSByaWNvbXBpbGF6aW9uZSBjb24gZGttcyBjb24gZ2xpIA0KPiBhZ2dpb3JuYW1l bnRpIGRlbCBrZXJuZWw/IA0KDQptYWksIG1hIGUnIGFuY2hlIHZlcm8gY2hlIG5vbiByaWF2 dmlvIHNwZXNzbyBlIGNvbXVucXVlIHVzbyB1biBrZXJuZWwgcHZlDQoNCi0tIA0KTWFyY28g QmVydG9yZWxsbw0KaHR0cHM6Ly93d3cubWFyY29iZXJ0b3JlbGxvLml0DQoNCg== --------------wCZvfUohtZr9O0NxzBe4gRy0
    Content-Type: application/pgp-keys; name="OpenPGP_0x5B7B17E82E9F51CE.asc" Content-Disposition: attachment; filename="OpenPGP_0x5B7B17E82E9F51CE.asc" Content-Description: OpenPGP public key
    Content-Transfer-Encoding: quoted-printable

    -----BEGIN PGP PUBLIC KEY BLOCK-----

    xsBNBFzGyDgBCADI2Tcg5ZmbeFZFXYiBaoK3gVE8KUmTkkmktVjbCJaYTv0/NM/b3ryVcHOP0I5j wQKTtAO9AML78RWg5YSRkaJRa05WSBQ62QsewnPzdeXN4dLonlVY7t5pUswlMnRkKOe06QN6wNPQ Afkfz9mM9tjGpfE7bF3Es33psPQiS6Rpb5uJ/kKEvCvypBp2I0gQBjqZGV8gmJrPcjjx++6nhr6M v69D73K+eG3zjw8hxIZADZ2Su+vf8xmPXvwdQka4RwOgIcQnRuJ8IJtRCZpwf5R7S38XUNTWJJXn FwdvlwxYNxxjcMfsW8heyimrjh8NKkbi7Ivw0LetF/y1bukPC9oXABEBAAHNKE1hcmNvIEJlcnRv cmVsbG8gPG1lQG1hcmNvYmVydG9yZWxsby5pdD7CwI4EEwEIADgWIQSghRQa3M9ySYg42a5bexfo Lp9RzgUCXMbIOAIbIwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRBbexfoLp9RzooWCADDQ6Ao +pfdDNhCeMhEo3JJHuaDm2B5jiQb+yn1rzc6/4G1ELojE8tAYHaRinQH4d6gutiro2qiyE13uGtP 9IcLdihjxFyZi52xjOyG5FVEY8fCrzSZRJZWi/8sqdnxR3eTHshma4zFqCCfLiVY4TQF7WqFF5j+ ow+8xmRlvrg1eh411NxevtI0JB5nAyYT4ep/ziDAgAzXe+NzYmsDEJ0rX/yXehJ81MO+/og1z4bs U8g8AJM/ggTSv7506GVYbcKW92t/BhDZXk+9lHgtgUgHHSr9rPq3Suj9kr8U9V1kzL8ZeOudY0Rj IegyBAHurg3sNY792u0Pnt7htECXySYGzsBNBFzGyDgBCADYkJFUiXyKYlBNsFW+AnGPc7kZXEuE n88njntw457mgoQZCScBY+WPr3Pb3mmrGMA0D3kzY+JLAnuZbCcYPtaHgYaF40IlgGho7Sb/BZGv FhLCiX4OTckY8a6HPkHHFNPW1wJV2FoinKdOfrUvrNnUKpAosxh2JcpV48tSBpFMOgPB+vc/ePqh r7EqrY8asuhhKj0BjVT/z3LJTD41VbWuZ3/eNBMoaHzF2gxfkXWPrh5I7CVPId8Ot0cnyscnLx+T Qj4FycS3RAT3n4IcDUWI2P+I1Iyf0F7jK0mJd7BKXQb/tuvJ3Dl6oDhBU1oibtpuz22P53E6ggVg TWjPItApABEBAAHCwHYEGAEIACAWIQSghRQa3M9ySYg42a5bexfoLp9RzgUCXMbIOAIbDAAKCRBb exfoLp9RziZhCACcOCNv/qLl1JjkoX76oILYFnG5tzAS6d6EPM7rl/0eWtGABGBdSrvhLEw9btGG qOsSUyet05wiV5TidB8lbeFgtxlaL/13uWcWUYwTvhPUKilK2CTYW5oBI1AGlqFLGWI+CeRbxMMA 9Wxe5JsEvuc+WWB2TdHa8H7N7egKUEkdh8fBvDt87m0cCEOBfXMtY2yVBvUh9boOy0IfRQKN5xf1 gvcOZcPIMngq2/dAzpGbYvX65wohG6s8BzdxXbKy7Opdb00au+f55zSvF8u2U0cAFeiaZVYavcXD bWgEFavGQAflplzGyi02cG3fPJiMe6vI72AvA8a4GlcIO3N5stCQ
    =d5vC
    -----END PGP PUBLIC KEY BLOCK-----
    --------------wCZvfUohtZr9O0NxzBe4gRy0--


    --------------xJvGy7OOt0kqXdS179YCXJxE--

    -----BEGIN PGP SIGNATURE-----

    wsB5BAABCAAjFiEEoIUUGtzPckmIONmuW3sX6C6fUc4FAmFv2bkFAwAAAAAACgkQW3sX6C6fUc4+ 6Qf/Yd1B8NQE99qEitCFLEaz3JcXX93Sa1IngQmf4ZYNdxrbQJn/EdSDO5AJMjhdYEEqxbJH8mfS eZFH2AAeD3cjncwEQwZmB5cqBKgfvHY74jyIGpPQzGr/hM4ocOSoRh6w4gWKsCVOU44lGzStwphu C/gWztpNZLGT7xEKL4Fy96fTX5XEiM6v4/Lid/raRqw1XWna+YTiP7s4TLGxByz3grW8WA2hOlOP U5AiuK8xM9q7iaUwLliIDMNoyUMolhKXBjLAfNBxaBN7ZCesFSwvgDKJ0s7z09kamG7I1XM/1zIA LcaKAGhoxNKeA0jJKiAhg9a5WICM3zWfi8UvglU9hg==
    =K2VJ
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)