Newsgroup: it.comp.os.linux.sys
Titolo: file system > 16tb

Ciao a tutti,
per dei software di backup abbiamo una cerca quantità di dati e stiamo 
sforando i 16tb, limite ad ora di ext4.
 
Non avendo necessità particolari di funzionalità, se non resize on-line 
e qualche decine di milioni di file sparsi in giro all'interno dell'fs, 
che opzioni più scalabili esistono?
Intendo esperienze dirette, magari crash e simili
 
Grazie

 che opzioni piï¿œ scalabili esistono?
 
La soluzione piï¿œ indicata per le tue esigenze, in termini di maturitï¿œ ed
affidabilitï¿œ, ï¿œ certamente XFS.
 
Essendo una soluzione di backup io penserei anche a btrfs... non ï¿œ
ancora definibile production-ready al contrario di XFS, ma supporta
deduplica e compressione dei files che consentono rispettivamente di
risparmiare molto spazio ed aumentare il throughput verso lo storage,
entrambe cose desiderabili.
 
Se quello storage ï¿œ parte di una soluzione di backup multi-tier
valuterei molto attentamente questa opzione (se invece ï¿œ l'unico backup
usa XFS e attrezzati per un ulteriore livello di sicurezza :) )
 
 
-- 
Flavio Visentin
 
Scientists discovered what's wrong with the female brain: on the left
side, there's nothing right, and on the right side, there's nothing left

 che opzioni pi� scalabili esistono?
 
ZFS.
 
Ciao Jack
-- 
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?

 sforando i 16tb, limite ad ora di ext4.
 
Secondo wikipedia il limite di ext4 e` 8EB (nota la "E").
I 16TB sono per un singolo file.
 
https://en.wikipedia.org/wiki/Comparison_of_file_systems
 
 
bye,
 
-- 
 
piergiorgio


Scusa era 1EB, ma non cambia molto.
 
bye,
 
-- 
 
piergiorgio


Sempre secondo wiki solo dalla versione 1.42
 


 
su ubuntu lts 12.04, versione 1.42, non mi permette di andare oltre 16tb
 
In rete si trovano mooolti post riguardo al limite, tutti con una
propria soluzione ma nulla che sia stabilmente in una distro stabile. E
quando si parla di queste quantità di dati, con annesso tempo di
eventuale ripristino (decine di ore), non vorrei ricostruire da bk (del
bk) qualora accada qualcosa che "non dovrebbe accadere" ;)
 
 
 
 


 
Almeno bk del bk, con soluzioni di sincronia automatica tra i due
 


 
Provato non molto tempo fa.
Forse perch�, sbagliando, ho abilitato la deduplica, ma non lo vedo "out
of the box".
 
Avevo tanto di quel iowait che mi sembrava di avere dei floppy sotto
anzich� un raid 6 con 16 meccaniche!
 
Per me un fs deve essere un mkfs.fs ed un mount.
Non una lettura di decine di pagine per capire che cosa e come
modificare arc, l2arc, kmem_size.
 
Ha le features migliori, ma no grazie.
 
Michele
 

 su ubuntu lts 12.04, versione 1.42, non mi permette di andare oltre 16tb
 
Interessante e buono a sapersi. CPU a 32 o 64 bit?
 
Ovviamente XFS sarebbe meglio, solo che devi, appunto
fare un po' di migrazioni...
Con tutti i rischi del caso.
 
bye,
 
-- 
 
piergiorgio

 
 
Seguendo i riferimenti si trova:
 
https://ext4.wiki.kernel.org/index.php/Ext4_Howto
 
 
Dove c'e`:
 
NOTE!
The code to create file systems bigger than 16 TiB is,
at the time of writing this article, not in any stable
release of e2fsprogs. It will be in future releases.
 
Che e` quello da cui RH sconsiglia volume > 16TiB.
 
Non e` chiaro, pero`, se sia ancora valido o meno...
 
bye,
 
-- 
 
piergiorgio


 
Ciao

 Ovviamente ci sarà fermo servizio, ma per il resto siamo in discesa.
 
Da quello che leggo in giro (mai provato di
persona) pare XFS sia "la" soluzione.
 
bye,
 
-- 
 
piergiorgio

 almeno dalle nostre prove) e tante belle ore.
 
Questo aspetto � stato molto migliorato nelle versioni recenti, diciamo 
dalla 3 in poi. Prima � vero per tanti file bisognava spezzare la 
sincronizzazione con pi� invocazioni a meno di non avere fantastiliardi 
di RAM.
 
-- 
Gabriele
 

 entrambe cose desiderabili.
 
scusate... sono solo io che vedo molto male le parole deduplica e backup 
nella stessa frase?
 
Mi spiego meglio: a mio avviso sono due concetti che fanno a cazzotti... 
se non ho capito male sarebbe come fare più copie di backup su N supporti 
e poi tenere 1 solo di questi supporti.
In altre parole ancora: faccio i miei backup sul disco e in maniera 
trasparente il file system elimina le copie ridondanti dei dati (con 
diverse tecniche). Cosa succede in caso di errore nel disco di backup?
 
Esempio banale: backup del file 'Docs/Documento1'
Senza deduplica:
copia lunedì: /backup/lun/Docs/Documento1
...
copia venerdì: /backup/ven/Docs/Documento1
 
se si guasta la superficie del disco e non riesco a leggere la copia di 
ven, ho sempre la speranza di riuscire a leggere una delle altre copie.
 
Con deduplica:
copia lunedì: /backup/lun/Docs/Documento1
...
copia venerdì: /backup/ven/Docs/Documento1
 
il file system 'ottimizza' i dati e tiene una sola copia di Documento1. 
In questo caso se non riesco a leggere il documento del backup di venerdì 
ho perso i dati...
 
Oppure ho capito male?
 
ciao
riki

 ven, ho sempre la speranza di riuscire a leggere una delle altre copie.
 
Stai trattando un caso limite che non ha a che fare con la deduplica
bensï¿œ con l'affidabilitï¿œ del supporto usato per il backup.
 
Innanzitutto se ti si guasta la superficie del disco e questo ti
impedisce di leggere i dati vuol dire che non stai usando un raid,
quindi il problema ï¿œ a monte della scelta del filesystem.
 
Poi non ï¿œ il caso specifico che bisogna valutare ma ï¿œ la generalitï¿œ del
funzionamento e della soluzione che va considerato.
P.es. se non hai la deduplica e ti si guasta l'unica copia del file
elaborato oggi cosa fai? Semplicemente perdi quei dati. E se ti si
guasta la superficie del disco in una parte contenente metadati del
filesystem cosa fai? Ancora perdi i tuoi dati. E se ti va a fuoco per un
corto circuito la NAS di backup senza la deduplica cosa fai? Nuovamente
ti attacchi al tram. Sono tutti casi in cui come vedi la deduplica ï¿œ
ininfluente rispetto all'inaccessibilitï¿œ del dato e sono tutti probabili
tanto quanto e forse piï¿œ del caso da te citato.
 
Quindi:
- ï¿œ meglio rischiare di pedere un documento per un evento "eccezionale"
come un guasto a due dischi (perchï¿œ per me il backup su storage ï¿œ
comunque sempre in RAID, se possibile RAID6) ma avere la possibilitï¿œ in
condizioni di funzionamento normale di mantenere un quantitativo di dati
fino a 10-15 volte superiore
oppure
- ï¿œ meglio scegliere di non usare la deduplica per tutelarsi dall'unica
tipologia di eventi che hai citato che affligge negativamente una
soluzione di deduplica ma poter mantenere solo un insieme minimo di
copie perchï¿œ ti manca spazio?
 
Il backup serve per recuperare dati ma ï¿œ giï¿œ di suo una seconda copia di
dati esistenti. Serve se si guasta la prima copia (quella in produzione)
ma non ha senso gestire un backup con la medesima tolleranza ai guasti
della produzione. Invece per il backup ï¿œ molto importante poter gestire
una retention corretta dei dati per poter ripristinare quelli corretti
in caso di problemi.
 
La produzione deve avere massima affidabilitï¿œ e massime performance, il
backup deve avere buona affidabilitï¿œ e perfomance accettabili, il
salvataggio di sicurezza del backup deve essere su media diverso e
mantenuto offline. Questo ï¿œ quanto basta per avere un ottimo sistema di
backup.
 
Se si perde la produzione e per sfiga si perde anche il backup si
riparte dalla copia di sicurezza e si sa che si sono persi alcuni giorni
di dati. Rientra nella situazione normalmente accettabile.
 
Poter tenere 10 versioni di un file nello spazio normalmente occupato da
due sole copie ï¿œ certamente sempre vantaggioso. Se per esempio a causa
della carenza di spazio hai solo le versioni degli ultimi due giorni di
un documento e questo si fosse corrotto la settimana prima come gestisci
la cosa? e stai pur certo che ï¿œ molto piï¿œ probabile questa situazione di
quella da te citata (a me ï¿œ capitato svariate volte).


ven, ho sempre la speranza di riuscire a leggere una delle altre copie.
 
Esatto anche questo. Quei venti backup sono affidati alla speranza. Lo
sono sempre stati. Ti casca il disco di mano UNA volta - e perdi venti
backup.
 
La deduplica ti toglie questa "speranza" e ti costringe, se vuoi avere
davvero ridondanza, ad avercela sotto forma di DUE supporti. Adesso ti
devono cadere di mano DUE dischi. Oppure ti serve una botta di stupido
per prenderli in mano tutti insieme, e una di sfiga per inciampare. La
somma e' sempre due :-)
 
Nota che tutto sommato la cosa potrebbe essere vantaggiosa: prima, per
quei venti backup ti serviva un tera. Con la deduplica, ti basta avere
- che so? - cento giga. Con due dischi da 160 GB ci stai largo - e hai
sempre venti backup (che "in hardware" [1] sono differenziali), con la
medesima spesa.
 
Leonardo approssimativo ma per dare l'idea
 
[1] OK, no. Diciamo "sotto al lato utente dell'IOSS"
 
-- 
 
Then felt I like some watcher of the skies, when a new planet swims into his ken;
Or like stout Cortez when with eagle eyes, he star'd at the Pacific; and all his men
Look'd at each other with a wild surmise - silent, upon a peak in Darien.

 No, il numero di supporti non cambia.
....
 
OK, mi avete convinto del fatto che, in ambito enterprise, la deduplica è 
cosa buona e giusta.
 
Non sono ancora così convinto che possa esserlo altrettanto nell'ambito 
del piccolo studio professionale / ufficio.
In questo caso infatti spesso il backup, se previsto, è affidato ad un 
disco usb esterno collegato al server (quando presente) e a qualche 
script / semplice software che periodicamente in modo automatico (o a 
mano) copia i file sul disco esterno.
Il mio disagio non ha comunque motivo di manifestarsi (per ora almeno) in 
quanto in questa situazione nel 99% dei casi il disco esterno avrà 
filesystem NTFS...
 
grazie 
riki

 Essendo una soluzione di backup io penserei anche a btrfs...
 
Io no, in quanto ancora non e` disponibile in RHEL (e derivate) una versione 
decentemente stabile e che supporti la deduplica (la compressione a quanto 
pare si)
 
Enrico
P.S. e` interessante notare che sono gli stessi concetti a cui sono arrivato 
io, solo che ho preferito svilupparli lato client (il mio sistema di backup 
emula la deduplica tramite hard link, e comprime i file con xz)

 emula la deduplica tramite hard link, e comprime i file con xz)
 
Backuppc che uso da diversi anni sfrutta il medesimo sistema.
Ma la deduplica block based raggiunge un livello di efficienza senza
rivali e fatta a livello di filesystem ï¿œ anche molto meno impattante.
Senza contare la funzionalitï¿œ di snapshotting anche a livello di
directory che consentono di gestire la retention dei dati in modo
semplicissimo.
 
Stavo effettivamente pensando di guardare se fosse possibile integrare
backuppc con btrfs per sfruttare a fondo le caratteristiche del
filesystem.... il problema come sempre ï¿œ il tempo.


 emula la deduplica tramite hard link, e comprime i file con xz)
 
Backuppc che uso da diversi anni sfrutta il medesimo sistema.
Ma la deduplica block based raggiunge un livello di efficienza senza
rivali e fatta a livello di filesystem ï¿œ anche molto meno impattante.
Senza contare la funzionalitï¿œ di snapshotting anche a livello di
directory che consentono di gestire la retention dei dati in modo
semplicissimo.
 
Stavo effettivamente pensando di guardare se fosse possibile integrare
backuppc con btrfs per sfruttare a fondo le caratteristiche del
filesystem.... il problema come sempre ï¿œ il tempo.
 
 


 filesystem.... il problema come sempre è il tempo.
 
Btrfs e` indubbiamente interessante, ma fino a che non esce dal suo stato di 
immaturita` e di instabilita`, non me la sento proprio di provarlo, nemmeno 
sui desktop (a tal proposito, gia` oggi l'installer di Fedora lo propone 
durante il partizionamento dei dischi)
 
Enrico