Re: Verso ZFS / BTRFS
Il 06/07/2013 11:34, Paride Desimone ha scritto: > Dovrebbe essere sufficiente dato che da quel che ho letto sulla ml di > zfsonlinux.org, 8 gb sono condizione sufficiente a farlo. Ad ogni modo ti > conviene molto probabilmente chiedere maggiori delucidazioni proprio a quella > ml, dato che hanno anche rilasciato la versione stabile, e che ci sono i > repository anche per debian. Avevo visto anche qualche cosa a riguardo di > debian, gsoc e zfsonlinux[1]. > > Paride Grazie Paride, ho deciso che lo proverò e vedrò un po' come gira così mi faccio un idea. Ciaoo -- Davide -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51d80d76.3030...@gmail.com
Re: Verso ZFS / BTRFS
Il 28/06/2013 19:22 Davide G. ha scritto: E' una macchinetta domestica che deve fare da fileserver "familiare" con quindi poche utenze, accesso saltuario e poche esigenze di prestazioni. La cpu è piccolina (1.6 Ghz 2 core fisici) ma ha 8 GB di ram che dato che non so cosa farmene uso in buona parte come tmps per share veloci e temporanee dato che in buona parte erano inutilizzati (o per operazioni lunghe su file come compressioni che faccio partire via ssh, mi porto via il portatile e quando torno le trovo finite). Parliamo di una macchina che fa solo fileserver e che nelle stesse condizioni su Ext4 aveva sempre un uso di risorse vicino allo 0%, che sarebbero quindi completamente a disposizione per ZFS. Dovrebbe essere sufficiente dato che da quel che ho letto sulla ml di zfsonlinux.org, 8 gb sono condizione sufficiente a farlo. Ad ogni modo ti conviene molto probabilmente chiedere maggiori delucidazioni proprio a quella ml, dato che hanno anche rilasciato la versione stabile, e che ci sono i repository anche per debian. Avevo visto anche qualche cosa a riguardo di debian, gsoc e zfsonlinux[1]. Paride [1]http://lists.alioth.debian.org/pipermail/soc-coordination/2013-March/001395.html -- http://keyserver.linux.it/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) -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/765b7e80bc6144121281c995fc600...@autistici.org
Re: Verso ZFS / BTRFS
.. non lo so.. ma ZFS non mi ha convinto. Anche se ZFS unisce più funzionalità tipiche di layer diversi in uno solo, continuerei a consigliare LVM2 + EXT4 + quello che ti serve (come le ACL estese, ecc). Personalmente uso (ancora per poco) un file server con un vecchio Xeon e 10 Gbyte da RAM su un controller RAID Hardware (HP 400i) e quella macchina è piegata in due da ZFS, avrà tanti punti a favore, ma penso che per sfruttarli a dovere o hai una dotazione adeguata oppure ... IMHO CIAO Luca -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130628192626.m67...@corep.it
Re: Verso ZFS / BTRFS
Il 28/06/2013 20:21, Pol Hallen ha scritto: > per questo non hai bisogno di un fs "avanzato": oltre ai classici > chmod/chown puoi usare le acl (e chattr) Vero, infatti questo lo facevo anche prima. >> - La directory principale era una share samba non "browseable" a cui solo un >> utente aveva accesso. > > valid users = user1,user2,ecc > browseable = no Come facevo prima quindi, ok. Pensavo servisse un metodo più pulito. >> - Per "nascondere" le cartelle non riguardanti gli altri 2 utenti anziché >> condividere le cartelle stesse, ne avevo creata una contenente al suo >> interno i >> solo link simbolici alle cartelle a cui gli altri 2 utenti potevano accedere. > > [...] > > (io) per non complicarmi la vita quando ci sono decine e decini di > utenti divisi per gruppi, ecc. > > ho le mie dir non-broseable, tipo: > > /samba/admin > > e per gli user: > > /samba/office/user1 > /samba/office/user2 > [...] > /samba/administration/user3 > /samba/administration/user4 > > e lavoro di chown Eh no, nel mio caso se facessi così dovrei duplicare gli stessi dati su tutti gli utenti. Certo la deduplicazione dei dati di ZFS snellirebbe il tutto ma avrei il problema che cancellare una cosa vorrebbe dire cancellarla da tutte le dir degli utenti. Nel mio caso preferivo un albero unico, e ogni utente accedeva ai "rami" che gli interessavano. >> Se usassi ZFS (o btrfs), quale sarebbe il modo corretto di "pensare" quanto >> scritto sopra? > > purtroppo non conosco questa funzionalità di zfs :-( ma qualcuno avrà > sicuramente una risposta :-) In realtà non credo esista una funzionalità del genere. Semplicemente condividevo dei link simbolici in modo che ognuno vedesse solo ciò che decidevo io. Speravo in una soluzione più pulita. >> Quello che mi chiedevo è: quando ho provato a creare un pool io lo vedevo non >> solo attivo, ma montato. Inoltre andando con "zfs get all" a chiedere i >> parametri, mi dava la conferma che il pool aveva già al suo interno un >> filesystem "radice" (dentro al quale posso ovviamente creare anche volumi >> ecc...). Perché creare un solo altro FS al suo interno? se non ho bisogno di >> crearne altri, perché non usare quello già presente? > > non ricordo la configurazione su freebsd però mi diventava utile > utilizzare più fs per gli snapshot online (quindi trasparenti al sistema) Vero, non ci ho pensato. Grazie ! >> Quello che cerco principalmente da questo passaggio è il checksum, gli >> snapshot, la possibilità di spostare l'archivio in blocco a un altro sistema >> (o >> backupparlo) con tutte le sue proprietà e mi sembra molto buono da un punto >> di >> vista di affidabilità il fatto che in caso di mirror o raidz il FS >> "collabora" >> col pool per la gestione degli errori (ad esempio checksum + mirror >> gestiscono >> il caso di corruzione "silenziosa" dei dati senza il rischio si sincronizzare >> il disco sbagliato). > > solo una domanda: che hardware usi? zfs (almeno su freebsd) per girare > in modo "normale" ha bisogno di almeno 8Gb di ram (meglio ECC). E' una macchinetta domestica che deve fare da fileserver "familiare" con quindi poche utenze, accesso saltuario e poche esigenze di prestazioni. La cpu è piccolina (1.6 Ghz 2 core fisici) ma ha 8 GB di ram che dato che non so cosa farmene uso in buona parte come tmps per share veloci e temporanee dato che in buona parte erano inutilizzati (o per operazioni lunghe su file come compressioni che faccio partire via ssh, mi porto via il portatile e quando torno le trovo finite). Parliamo di una macchina che fa solo fileserver e che nelle stesse condizioni su Ext4 aveva sempre un uso di risorse vicino allo 0%, che sarebbero quindi completamente a disposizione per ZFS. A Luca invece: > Ciao ! > > Uso da diverso tempo ZFS in BSD e lo trovo terribilmente pesante, affamato di > memoria e lento. > Probabilmente se usi una super macchina è anche un bel file system, anche se > non è un file system ZFS, ma molto di più. > > Mha, non lo so.. ha pregi e difetti, dipende per cosa lo usi e soprattutto su > cosa lo usi. Vedi quanto scritto sopra. Samba mi usa un solo core al 100% durante i trasferimenti lasciandomi l'altro libero e viaggio a 40 MB/s, che per l'uso casalingo sono più che sufficienti. Se l'altro core a ZFS basta per lavorare a 40MB/s allora sono tranquillo (anche un po' meno andrebbe bene). Non ne ho bisogno, però se i difetti non mi sono di impiccio potrebbe farmi comodo e già che ci sono mi faccio un po' di esperienza in quest'ambito. Su btrfs invece? nessuna opinione? Ciao Davide -- Davide -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51cde27c.5000...@gmail.com
Re: Verso ZFS / BTRFS
Ciao, ti rispondo in parte e ti premetto che uso zfs su freebsd (su linux non ho ancora avuto necessità). > - Directory principale condivisa a cui un solo utente ha pieno accesso > - Diverse cartelle di cui solo alcune visibili e accessibili (e eventualmente > scrivibili) da altri 2 utenti. > - In alcuni (pochi) casi la regola scritta appena sopra deve valere anche per > le sottocartelle. per questo non hai bisogno di un fs "avanzato": oltre ai classici chmod/chown puoi usare le acl (e chattr) > - La directory principale era una share samba non "browseable" a cui solo un > utente aveva accesso. valid users = user1,user2,ecc browseable = no > - Per "nascondere" le cartelle non riguardanti gli altri 2 utenti anziché > condividere le cartelle stesse, ne avevo creata una contenente al suo interno > i > solo link simbolici alle cartelle a cui gli altri 2 utenti potevano accedere. [...] (io) per non complicarmi la vita quando ci sono decine e decini di utenti divisi per gruppi, ecc. ho le mie dir non-broseable, tipo: /samba/admin e per gli user: /samba/office/user1 /samba/office/user2 [...] /samba/administration/user3 /samba/administration/user4 e lavoro di chown > Se usassi ZFS (o btrfs), quale sarebbe il modo corretto di "pensare" quanto > scritto sopra? purtroppo non conosco questa funzionalità di zfs :-( ma qualcuno avrà sicuramente una risposta :-) posso dirti che da vista in poi (e usando lvm) puoi rendere disponibile le shadow copy ma è una funzionalità di lvm. > Quello che mi chiedevo è: quando ho provato a creare un pool io lo vedevo non > solo attivo, ma montato. Inoltre andando con "zfs get all" a chiedere i > parametri, mi dava la conferma che il pool aveva già al suo interno un > filesystem "radice" (dentro al quale posso ovviamente creare anche volumi > ecc...). Perché creare un solo altro FS al suo interno? se non ho bisogno di > crearne altri, perché non usare quello già presente? non ricordo la configurazione su freebsd però mi diventava utile utilizzare più fs per gli snapshot online (quindi trasparenti al sistema) > Quello che cerco principalmente da questo passaggio è il checksum, gli > snapshot, la possibilità di spostare l'archivio in blocco a un altro sistema > (o > backupparlo) con tutte le sue proprietà e mi sembra molto buono da un punto di > vista di affidabilità il fatto che in caso di mirror o raidz il FS "collabora" > col pool per la gestione degli errori (ad esempio checksum + mirror gestiscono > il caso di corruzione "silenziosa" dei dati senza il rischio si sincronizzare > il disco sbagliato). solo una domanda: che hardware usi? zfs (almeno su freebsd) per girare in modo "normale" ha bisogno di almeno 8Gb di ram (meglio ECC). Pol -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51cdd42a.9050...@fuckaround.org
Re: Verso ZFS / BTRFS
Ciao ! Uso da diverso tempo ZFS in BSD e lo trovo terribilmente pesante, affamato di memoria e lento. Probabilmente se usi una super macchina è anche un bel file system, anche se non è un file system ZFS, ma molto di più. Mha, non lo so.. ha pregi e difetti, dipende per cosa lo usi e soprattutto su cosa lo usi. CIAO Luca -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130628180957.m19...@corep.it
Verso ZFS / BTRFS
Un ciao a tutta la lista. Stavo valutando la migrazione verso un FS più "avanzato" come quelli descritti sopra. Valutavo principalmente ZFS usando il modulo del kernel zfsonlinux ma anche btrfs sembra abbia le funzionalità che cerco. Ho notato che anche da un punto di vista di mentalità sono molto diversi dai FS più semplici con cui sono abituato a lavorare. Ho anche visto che zfs include una specie di "condivisione samba" che potrebbe essere molto comoda. A parte ogni consiglio/considerazione riguardo ai 2 FS citati, vorrei sapere quale sarebbe "concettualmente" il modo migliore per fare ciò che facevo prima su ext4 mantenendo samba come protocollo di condivisione: - Directory principale condivisa a cui un solo utente ha pieno accesso - Diverse cartelle di cui solo alcune visibili e accessibili (e eventualmente scrivibili) da altri 2 utenti. - In alcuni (pochi) casi la regola scritta appena sopra deve valere anche per le sottocartelle. Prima per gestire quanto sopra avevo fatto così (so che non è pulitissimo ma andava): - La directory principale era una share samba non "browseable" a cui solo un utente aveva accesso. - Le cartelle (e loro sottocartelle) avevano i permessi settati secondo quanto necessario. - Per "nascondere" le cartelle non riguardanti gli altri 2 utenti anziché condividere le cartelle stesse, ne avevo creata una contenente al suo interno i solo link simbolici alle cartelle a cui gli altri 2 utenti potevano accedere. Cioè io ho: / /A (da non condividere) /B (da condividere) /C/1(da non condividere) /C/2(da condividere) e una cartella D così strutturata /D/B(link a B) /D/C/2 (link a /C/2) In questo modo gli altri utenti vedevano la share D, e io invece accedevo alla radice "non visibile". Se usassi ZFS (o btrfs), quale sarebbe il modo corretto di "pensare" quanto scritto sopra? Aggiungo inoltre riguardo a ZFS: Su internet leggo che molti dopo aver creato il pool, creano un FS al suo interno. Il fatto che si posso creare filesystem uno contenuto all'altro con proprietà e quote diverse l'ho capito. Quello che mi chiedevo è: quando ho provato a creare un pool io lo vedevo non solo attivo, ma montato. Inoltre andando con "zfs get all" a chiedere i parametri, mi dava la conferma che il pool aveva già al suo interno un filesystem "radice" (dentro al quale posso ovviamente creare anche volumi ecc...). Perché creare un solo altro FS al suo interno? se non ho bisogno di crearne altri, perché non usare quello già presente? Quello che cerco principalmente da questo passaggio è il checksum, gli snapshot, la possibilità di spostare l'archivio in blocco a un altro sistema (o backupparlo) con tutte le sue proprietà e mi sembra molto buono da un punto di vista di affidabilità il fatto che in caso di mirror o raidz il FS "collabora" col pool per la gestione degli errori (ad esempio checksum + mirror gestiscono il caso di corruzione "silenziosa" dei dati senza il rischio si sincronizzare il disco sbagliato). Se ho detto castronerie correggetemi perché quello di questi FS per me è un mondo tutto nuovo e non ho ancora capito come funziona l'approccio mentale. Ciao e grazie a tutti Davide -- Davide -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51cdce28.5080...@gmail.com
