Newsgroup: it.comp.os.linux.sys
Titolo: FS compresso

Mi piacerebbe utilizzare un fs compresso per i dischi su cui dovro' fare 
i backup differenziali.
Qualche consiglio o sconsiglio?
Ciao ... Dino

 un cretino ha scritto:
"Il microkernel e' morto da molto tempo ed ancora non lo sa." (cit. Bluff)

 maggioranza degli utilizzi.
Non ho bechmark per affermare che questo non sia vero nemmeno nel caso
particolare di cui sto facendo qualche esperienza, ma almeno a livello
di impressione lessfs (filesystem implementato con algoritmi di
deduplicazione e con fuse, arrivato alla versione 1.01) mi sembra
avere prestazioni accettabili e pure fare il suo lavoro non male, dato
che mi ha ridotto 90 GB di film ed mp3 (quindi materiale di per se`
quasi incomprimibile o per il quale con i normali algoritmi di
compressione si rischia di ottenere un effetto contrario a quello
voluto o nullo) a meno di  70 GB (ho rsyncato da filesystems ext4 a
lessfs su reiserfs - i metadati erano salvati su quel filesystem),
quindi con un guadagno superiore al 20%.
Per le prestazioni devo andare a stima perche' non le ho misurate, ma
diciamo che ha fatto quel lavoro in circa 3-4 ore con un Intel E7500 e
parecchia RAM (anche se non ne e` mai stata usata molta) su un disco
esterno USB2 credo da 5400 rpm. Comunque non credo che se avessi usato
gzip, per non parlare di bzip2, avrei ottenuto dei tempi molto
diversi, mentre sicuramente avrei ottenuto nelle migliori delle
ipotesi un guadagno del 2-3% sull'occupazione di spazio.
Andrea


ZFS, opensolaris. Ma se comprimi di default non te ne accorgi neanche, se 
comprimi con gzip dopo piangi.

 Andrea
ciao
riki

 se ne accorge e li 'hardlink()a'? (scusa il neologismo)
Un filesystem che deduplica fa proprio questo, ma non a livello di file 
bens� di blocco. La probabilit� di avere due blocchi uguali � maggiore di 
quella di avere due file uguali, quindi la deduplica dei blocchi � pi� 
efficiente.
Certo � che personalmente non terrei mai dei dati importanti su un 
filesystem deduplicato, perch� in caso di corruzione le probabilit� di 
recupero dei dati � sensibilmente inferiore ad un FS standard. in questo 
caso � certamente preferibile un sistema di deduplica a livello di file come 
quelli implementati da backuppc o da rsnapshot.



c'è tantissimaa scelta:
btrfs, ma è in fase di sviluppo.
advfs, ma è in fase di sviluppo e non credo faccia ancora parte dei 
kernel vanilla. Puoi provare a vedere i kernel strawberry... se riesci a 
trovarli :P
se vuoi fare da tester, e riportare qui i risultati della tua 
esperienza, te ne saremo tutti infinitamente grati :-)
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
   printf $i }'; echo

 esperienza, te ne saremo tutti infinitamente grati :-)
Veramente sarebbe un backup che DEVE funzionare, non e' una cosa per 
divertirmi a casa :D
Ciao ... Dino


Spiegati meglio.
Ciao ... Dino

 quelli implementati da backuppc o da rsnapshot.
Mah .... A questa stregua non solo non dovresti usare dell'hw di
deduplicazione (
p.es
. Exagrid) per dati di backup importanti, ma
nemmeno comprimere dati importanti anche a livello di file perche'
anche in quel caso se ti si corrompe il file compresso (metti un file
da diverse decine di GB)
il rischio di perderlo tutto o di perderne di piu` e` maggiore che se
il file non fosse stato compresso.
Non nego che il rischio possa essere maggiore, ma si tratta di capire
bene di quanto lo sia e se sia accettabile. Se usi dell' "hardware
sano" (TM), e magari non solo quella copia di backup (ma 
p.es
. anche
una su nastro, DAT, LTO) credo che rischi di questo genere siano
abbastanza ridotti e/o controllati/controllabili.
Piuttosto la cosa che trovo interessante e meritevole di essere
implementata bene e/o automatizzata, e` il controllo di integrita` e
consistenza di cio` che viene salvato prima del salvataggio ed anche
dopo, per verificare sia di non star salvando dati gia` corrotti, sia
di poter ripristinare gli stessi dati che sono gia` stati salvati.
Adesso sto usando AIDE per la fase 1, anche se la cosa e` ancora da
automatizzare e raffinare, mentre per la seconda fase si tratterebbe
di testare cio` che e` stato salvato con i checksum gia` calcolati
nella prima fase. Pero` mi chiedo se non ci siano metodi piu`
efficienti, dato che questo e` lunghetto (file per file e directory
per directory passano le ore).
Andrea

 per directory passano le ore).
Backuppc per esempio lo fa dato che salva il contenuto dei file utilizzando 
l'hash del contenuto come nome rendendo verificabile a posteriori 
l'integrit� di ogni file. La deduplica la fa schedulata a livello di singolo 
file, quindi non � cos� efficiente come un FS dedicato, ma le possibilit� di 
gestione che offre sono impareggiabili.



La prima e' autoesplicativa. Nel secondo caso devi avere una cpu molto 
potente e molta pazienza nella scrittura.
E comunque ZFS usa un sacco di spazio di default, e quando superi l'80% di 
occupazione tende a fare stranezze. Se poi decide di perdersi i files - 
non che lo faccia sovente - lo fa per benino e li perde tutti. E non 
esiste il check per zfs.


Allora ciao ciao zfs :)
Ciao ... Dino

 dischi odierni... PERCHE' usare un fs compresso?
Perche' 2TB sono meglio di 4 :)
Ciao ... Dino


Non ne sto parlando male. Ci puoi fare anche parecchie cose carine, come 
raidz.
Pero' certe cose bisogna saperle prima, non affidarsi al marketting di Sun.

 gestione che offre sono impareggiabili.
Grazie. Approfondiro` Backuppc.
Andrea

 anche, ma non è lo strumento più indicato.
Ma per la verifica dell'integrita` e della consistenza prima del
backup, che puoi usare? Non credo che Backuppc la faccia, la fara` di
cio che prende in carico, non prima di prenderlo in carico, mentre
AIDE o chi per lui, ti permette di verificare (anche se con qualche
contorsione) che 
p.es
. non ti si sia corrotto un filesystem prima di
un backup, nella misura in cui ti troveresti senza motivo un numero
abnorme di files che hanno cambiato hash rispetto al giro prima del
programma, da cui potresti soprassedere al backup e, fatte le
opportune verifiche e correzioni, operare un ripristino invece di un
backup.
Andrea


'mmazza sei uno di quelli che spacca il Tera in quattro :-)


 Grazie. Approfondiro` Backuppc.
Scoprirai un mondo nuovo :-)
Ti consiglio di utilizzare reiserfs per il filesystem su cui ospiti il pool 
di backup.



bah .... sto elucubrando .....
sai cosa farei se avessi un file danneggiato? Proverei ad lanciare:
ddrescue if=blabl blabla
E, riusciresti a recupare (cosa utile in certi casi) ci� che c'� prima, 
e ci� che c'� dopo la corruzione del dato.
Ma un file compresso che ci fai? Puoi fare la stessa cosa, ma poi, se 
fai zcat, credo che ti esca fuori appena arriva al punto in cui il file 
� corrotto.
Esiste un 'zcatrescue' :-)


 ddrescue if=
Ehm...:-)

 backup.
Se hai un enorme numero di file diversi a causa di una corruzione te ne 
accorgi ben prima di AIDE dato che ti si riempiono i log e la console di 
messaggi di errore :-)
Anyway la domanda posta inizialmente ("serve realmente a qualcosa?") ha una 
risposta ben definita: AIDE non ha alcuna utilità pratica per salvaguardarsi 
da corruzioni di FS.
Se ti accorgi che il FS è corrotto lo devi restorare, non ci si scappa: se 
te ne accorgi prima di fare il backup restorerai l'ultimo backup in tuo 
possesso, se te ne accorgi dopo o durante restorerai il penultimo perché 
l'ultimo sai che non è buono; il lavoro necessario è comunque sempre lo 
stesso. L'importante è che tu abbia i backup, che siano funzionanti e che 
abbia programmato una buona schedulazione che ti permetta di ritornare 
indietro di un congruo numero di giorni.
Comunque non è assolutamente difficile utilizzare backuppc come integrity 
checker; ti basta confrontare due backup di un host che non sono altro che 
due directory.
Lo storage di backuppc è fatto così:
/var/lib/backuppc/cpool/
/var/lib/backuppc/cpool/0
/var/lib/backuppc/cpool/0/0
/var/lib/backuppc/cpool/0/0/0
/var/lib/backuppc/cpool/0/0/0/0003b64493116841815d352bd7b175e7
/var/lib/backuppc/cpool/0/0/0/000da23909e3c2a25aedc20b359c5a1b
/var/lib/backuppc/cpool/0/0/0/000611a2ad9ae1289b6260a02fcac985
/var/lib/backuppc/cpool/0/0/1
/var/lib/backuppc/cpool/0/0/2
/var/lib/backuppc/cpool/0/0/3
/var/lib/backuppc/cpool/0/1
/var/lib/backuppc/cpool/0/2
/var/lib/backuppc/cpool/1
/var/lib/backuppc/cpool/2
/var/lib/backuppc/cpool/f
/var/lib/backuppc/cpool/f/f
/var/lib/backuppc/cpool/f/f/f
/var/lib/backuppc/cpool/f/f/f/ffffcbbe7c2a683998fb105c6f24448f
Ovviamente in mezzo ci sono migliaia di files e tutta la struttura tipica 
usata nelle cache.
Il singolo host invece viene backuppato in /var/lib/backuppc/pc/$hostname 
salvando le dir con una "f" davanti al nome e url-encoded.
P.es. il backup della macchina dumbo contiene (tra le altre):
/var/lib/backuppc/pc/dumbo/
├── 368
│   ├── attrib
│   ├── backupInfo
│   ├── f%2fusr%2flocal
│   │   ├── attrib
│   │   ├── fbin
│   │   ├── fgames
│   │   ├── finclude
│   │   ├── flib
│   │   ├── fman
│   │   ├── fsbin
│   │   ├── fshare
│   │   └── fsrc
│   └── f%2fvar%2flib%2fmysql
│       ├── attrib
│       ├── fdebian-5.0.flag
│       ├── fdebian-5.1.flag
│       ├── fibdata1
│       ├── fib_logfile0
│       ├── fib_logfile1
│       ├── flost@002bfound
│       ├── fmysql
│       ├── fmysql_upgrade_info
│       └── fmythconverg
├── 369
│   ├── attrib
│   ├── backupInfo
│   ├── f%2fusr%2flocal
│   │   ├── attrib
│   │   ├── fbin
│   │   ├── fgames
│   │   ├── finclude
│   │   ├── flib
│   │   ├── fsbin
│   │   ├── fshare
│   │   └── fsrc
│   └── f%2fvar%2flib%2fmysql
│       ├── attrib
│       ├── flost@002bfound
│       ├── fmysql
│       └── fmythconverg
├── 370
...
Se vuoi vedere quali file sono cambiati tra il backup 368 e il 369 basta che 
controlli se i file dell'uno e dell'altro puntano allo stesso inode. Senza 
andare sul complesso una cosa come questa è sufficiente (magari in uno 
script parametrizzato)
# find 369 -type f -name f\* | while read file
 > do
 >    inode1=$(ls -i $file 2>/dev/null| cut -f1 -d' ')
 >    inode2=$(ls -i 370/${file##369/} 2>/dev/null| cut -f1 -d' ')
 >    [ "$inode1" == "$inode2" ] || echo $file changed
 > done



io no capire prima. Adesso installato tool, io capire tutto :-)
e scrivere così altra volta: ddrescue infile outfile



Questa non la sapevo. Però, guarda qua cosa trovo:
Given that the fsck utility is designed to repair known pathologies 
specific to individual file systems, writing such a utility for a file 
system with no known pathologies is impossible.
E in un altro sito viene detto:
ZFS does not have a fsck tool. Because it doesn't need one.
sarà mai che noi linuxari ci stiamo perdendo qualcosa assolutamente 
imperdibile?
Aggiungo che, pure XFS non ha un fsck: esiste per compatibilità con gli 
initscript. Ma non fa assolutamente nulla e da sempre un exit status 
uguale a zero: una specie di true.
Tuttavia, xfs ha l'xfs_repair


 ZFS does not have a fsck tool. Because it doesn't need one.
Mai visto ZFS neppure da lontano, ma queste due cose messe
assieme mi danno l'idea che con ZFS o hai tutti i file, o non li hai pi�.
-- 
ValeRyo
XT600 "Katoki Pajama" - 
http://www.slimmit.com/go.asp?7Y9
CBR600F "Cerbero" - In vendita - 
http://www.slimmit.com/go.asp?7X0
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
 

 pool di backup.
Giusto per curiosita`, perche`?
Enrico
P.S. sembra carino Backuppc, sarei pero` interessato a capire se gestisce 
l'estrazione dei dati da database e se archivia su cassetta (quest'ultima 
penso che la faccia)

 sono altro che due directory.
[...]
grazie ancora.
Andrea

 e se archivia su cassetta (quest'ultima penso che la faccia)
E invece no :-) Al momento non esiste ancora questa possibilit�, ma pu� 
creare degli archive set che sono in pratica l'ultimo backup di ogni 
macchina da poter salvare su cassetta o su altro supporto.
Il targer di backuppc � normalmente il backup su disco dei client.
Se il motivo per salvare su tape � al fine del disaster recovery, il metodo 
pi� pratico � quello di fare uno snapshot del LV e dare un semplice
# cat /dev/vg0/backuppc > /dev/st0
Ovviamente di domenica perch� deve copiare tanti dati e ci mette parecchio 
(normalmente il pool � di un centinaio di GB o pi�). Fare un trasferimento 
dei dati su tape attraverso la lettura dell'intero filesystem � un suicidio.


 stava cambiando sotto i piedi del programma che faceva il check.
Infatti non si può fare. Ma anche se si potesse fare non cambierebbe molto. 
Tanto non potresti comunque ripararlo senza metterlo offline. Se fosse un FS 
non molto acceduto potresti fare un sync e poi uno snapshot e fare l'FSCK 
dello snapshot; a rigor di logica deve poter andare, ma non vedo comunque 
utilità nel farlo.


 ZFS does not have a fsck tool. Because it doesn't need one.
Il classico blabla che conoscono tutti.
Ne trovi tante, tipo:
The author of the article analyzes the implications of not having a fsck 
tool and tries to explain why he thinks Sun will add one at some point.
Giocando un po' con zfs ti rendi conto di quanto facile sia perdere intere 
partizioni. Con buona pace dello scrubbing e del marketting.


"why he thinks Sun will add one..." Bisogna vedere cosa ne pensa Sun di 
quel che pensa l'autore di quell'articolo :-)
Comunque forse scoveranno le nuove condizioni che possono determinare le 
perdite di dati.
Non so che dire veramente. E tutta questa cosa mi ha anche un po' stupito.


 utilità nel farlo.
No, un attimo, l'utilita` la vedo eccome. E' come fare un esame
diagnostico che ti permette di sapere se hai il cancro o no. Poi certo
che se ti devi curare e/o operare, ti dovrai fermare, prendere giorni
di malattia, ferie o che altro, ma appunto agisci di conseguenza e ti
curi. Se non lo sai continui a funzionare senza curarti e fermarti, ma
poi schiatti.
In questo caso, tanto per dirne una, se rilevi inconsistenze non fai
il backup di quel filesystem cosi` com'e`, ma almeno prima gli fai un
check.
Andrea

 check.
Non hai afferrato il concetto che volevo esprimere. Se l'inconsistenza del 
filesystem � seria allora il backup, che scorre tutte le directory per 
verificare i files da salvare, sicuramente sollever� il problema che verr� 
cos� riportato nei log, e un classico logwatch o la console ti informeranno 
del problema.
Se in occasione del backup non si evidenziano problemi pu� significare solo 
due cose: 1) non c'� corruzione o 2) che la corruzione non � significativa e 
comunque non impatta sulla lettura dei file, perch� altrimenti verrebbe 
"triggerata" dal backup.
Per le corruzioni del secondo tipo c'� appositamente l'fsck ogni 180 giorni 
o ogni 30 mount che � pi� che sufficiente. Considera che la corruzione di un 
filesystem normalmente pu� avvenire solo in tre occasioni, tutte piuttosto 
rare: in caso di bug nel driver, in caso di crash (kernel panic, riavvio 
forzato), in caso di hardware difettoso.
Il primo caso possiamo in linea di massima scartarlo sui filesystem pi� 
comuni, e comunque un backup normalmente lo rileva; nel secondo caso si 
esegue automaticamente un fsck al riavvio, quindi non c'� problema, nel 
terzo caso normalmente la merda alta e l'effetto � comunemente un crash di 
sistema o una sfilza di errori nel log.
Per questo dico che non ha senso un fsck a runtime, perch� se hai problemi 
te ne accorgi comunque.


 Secondo me i f.s. compressi sono morti negli anni 80 con Stacker.
Lo dico in base ai file che so dovranno essere backuppati. Con la 
compressione ntfs piu' o meno sono al 50%. Mi spiacerebbe dover sprecare 
spazio proprio sui dischi di backup.
Ciao ... Dino

 te ne accorgi comunque.
La domanda e`: sempre? o meglio, sempre in tempo?

 Ma se usi un filesystem 'normale', sei sicuro di quanto ottieni.
"Un" file. Su N files puoi avere una stima ragionevolmente abbastanza
accurata, a maggior ragione se sai di che tipo di files si tratta. P.
es. su una bella raccolta di testi semplici ti puoi aspettare un
valore attorno all' 1 a 10, che anche se i dischi costano poco, non
costano cosi` poco per non parlare del fatto che i dischi che non ci
sono non possono rompersi.

 quel che pensa l'autore di quell'articolo 
Che se non si sbrigano qualche utente lo perdono. Dopo tanti anni di 
sviluppo e tanto hype - zfs the ultimate fs - and so on, trovare che abbia 
l'affidabilita' di ext2 versione 0.01 non e' grandioso.

 sviluppo e tanto hype - zfs the ultimate fs - and so on
zfs: the last word in the filsystema era :-)


 La domanda e`: sempre? o meglio, sempre in tempo?
La risposta �: sempre, ma sempre troppo tardi :-)



io lo so che mi beccher� un bel vaffanculo, per� ntfs � compresso... :)


                                                           ^
scusa, comprimibile

On 02/02/2010 23:08, Francesco Paolini wrote:

non da me.
Sono l'unico qui dentro che sostiene che ntfs � sempre stato superiore 
rispetto ai vari extN.
non ti preoccupare, mo' tutti i vaffanculo me li becco io :)



con N != 4 :-)
non so... magari ext4 ha davanti un futuro roseo :-)


 Giusto per ] zac [
hai abbandonato XPN? ... pure io settimana scorsa l'ho mandato a 
catafottersi :-)


 rispetto ai vari extN.
Dati oggettivi, grazie.

 io lo so che mi beccher� un bel vaffanculo, per� ntfs � compresso... :)
Sei andato a prendere una delle pochissime features di NTFS che non lo 
relegano a FS di serie C :-) L'altra feature degna di nota IMHO sono gli ADS 
che se fossero gestibili in modo semplice rappresenterebbero una validissima 
risorsa (gli attributi estesi su Linux sono limitati da questo punto di vista).



è comprimibile :-)
adesso dati oggettivi al contrario



Ehm.... non so se ti rendi conto, ma stai rispondendo seriamente a 
*Max_Adamo*. Dalle mie parti si dice "No se ghen cava, sanc da na rava".



Parla con me invece di triturare i coglioni all'infinito per conto terzi.
Altrimenti piantala una volta per tutte con questo stabat mater, che 
invece di essere un patetico piagnisteo sta iniziando a dioventare una 
rottura di coglioni, cui è sempre più difficoltoso dover assistere.
Torna alle tue discussioni con altri, dove imperterrito puntualizzi 
all'infinito la differenza tra un pelo di culo e un pelo di coglioni.


 (gli attributi estesi su Linux sono limitati da questo punto di vista).
Uh? non so/non ricordo cos'ho con ADS, ma con linux ho (oltre agli attributi 
POSIX):
 - Attributi estesi (man attr);
 - Attributi avanzati (man chattr);
 - ACL (man acl).
Cosa ti da in piu` ADS?
Enrico
P.S. se Tracker, Nepomuk o qualsiasi altro search indexer utilizzassero gli 
attributi estesi, saremo molto piu` contenti (se non sbaglio l'unico che ne 
fa uso e` Beagle)

 catafottersi :-)
E` dalla discussione relativa alla petizione "pro" MySQL che l'ho 
abbandonato, visto che la ricerca nei post inviati non esiste. Devo dire 
pero` che il passaggio a KNode non mi soddisfa molto, in quanto mi lega al 
client (ovvero non ho modo di esportare il jnewsrc), anche se il fatto che 
non si crea delle cache gioca molto a suo favore
Enrico

 l'unico FS che la supporta) si risparmia tantissimo spazio.
Ottime argomentazioni, se non fosse lo stato in cui riversa tale file system 
(ovvero, di manutenzione). Inoltre, considerando vari test[1], ReiserFS non 
sembrerebbe cosi` efficiente come sembra. Ad esempio, seguendo anche il tuo 
discorso, sembrano essere molto piu` efficienti XFS o JFS: il primo in 
quanto ha performance in alcuni casi migliori su grossi alberi di directory 
(ricordiamo che ReiserFS e` ottimo sui file piccoli, ma difficilmente si 
rientra in quei parametri). Il secondo in quanto, oltre ad avere il supporto 
al Block suballocation (o tail merge), ha un impatto sulla cpu piu` basso 
rispetto agli altri file system
Enrico
[1] vecchio, ma direi sempre abbastanza valido: 
http://www.debian-
administration.org/articles/388

 relegano a FS di serie C :-)
Quindi in sostanze e' vero che la compressione alla ntfs non c'e' in 
altro fs? Mi tocca usare proprio ntfs anche sotto linux sui dischi di 
backup?
Ciao ... Dino

 backup?
ZFS ce l'ha :)
-- 
Vide

 adesso dati oggettivi al contrario
Facciamo così: stabilisci *tu* una serie di parametri che ritieni importanti in un FS
e poi analizziamo tali parametri in ntfs e ext3, ok?

 *Max_Adamo*. Dalle mie parti si dice "No se ghen cava, sanc da na rava".
Sono un maieutica-addicted, sorry. <g>


Posso fidarmi di zfs piu' di ntfs?
Ciao ... Dino


"resilienza" (*): questo è il termine perfetto. Sicuramente rispetto a 
ext2, del quale era coevo. Secondo me vince anche contro ext3, ma è 
difficilmente quantificabile.
"extent": gli extent compaiono OGGI con ext4
"dimensione massima di un file": ntfs vince a mani basse
"dimensione massima del volume": ntfs vince.
"compressione trasparente": lo abbiamo già detto.
ntfs ha invece uno strano limite nel nome di un file di 255 caratteri 
(che secondo me potrebbe essere addirittura in tutta la lunghezza del path)
Mi pare che ci siamo. O no?
(*) non in senso informatico, ma come viene inteso in ingegneria:
http://it.wikipedia.org/wiki/Resilienza_(ingegneria)


 Parla con me invece di triturare i coglioni all'infinito per conto
Dai, ora la bestemmia, come ci hai abituato...

> e poi analizziamo tali parametri in ntfs e ext3, ok?
Aggiungo io: fai che ci dici anche a quale versione di NTFS ti riferisci
nei tuoi rantoli, che quella che adesso in W2K8 e quella roba che c'era
in NT4 stanno tra loro come ext4 sta al filesystem di minix...
Per la mia esperienza personale, i problemi di filesystem con la
famiglia ext* sono finiti (salvo bug transitori specifici della singola
kernel release) da qualche parte tra gli ultimi kernel 2.2...
In uso *server*, ovviamente.
-- 
Professional System & Network Sarcazzer
http://bofhskull.wordpress.com/


evaristo pensaci tu a questo qua :-)


 kernel release) da qualche parte tra gli ultimi kernel 2.2...
io direi: tra gli ultimi 2.4, se mi permetti.
p.s.: che avesse un FS migliore, non vuole dire che fosse un sistema 
migliore. Non ve la prendete tanto.



Altre cose un po' fuori Topic:
aggiungo: la presenza del raid software in windows era già stabile nel 
primo win NT 4.0 e i primi raid software stabili su linux non so a 
quando risalgono. Ma le CPU a 100Mhz di allora facevano preferire di 
gran lunga il raid hardware. Ma questo non riguarda il FS.
aggiungo: in entrambi, ntfs e extN, manca un layer *embedded* di 
gestione volumi logici. Cosa che avremo con btrfs. Ma anche questo non 
riguarda il FS.


 così come ci sono stati in XFS.
ntfs-3g, fra l'altro, legge tutte le versioni di NTFS. Dubito che 
autodifferenzi tra versione con e senza extent.


 Posso fidarmi di zfs piu' di ntfs?
Su Linux? Non ho dati certi però presumo che, specie sul tuo HW che non è 
nuovo, sia meglio ntfs-3g rispetto a ZFS via FUSE. 
-- 
Vide

 
administration.org/articles/388
Personalmente sono convinto che l'unico modo sia provare. Ogni test è un 
caso a sè.



Mi fa un po' strano usare ntfs su linux :D
Fino ad ora mi e' capitato solo per compatibilita' o per dischi usb.
Ciao ... Dino

 sprecare spazio proprio sui dischi di backup.
Potresti provare con squashfs che però è readonly.
Invece di copiare i file su un fs compresso, crei un'immagine compressa 
dei dati. Per il restore, dipende: se ti servo solo qualche file, lo 
monti in loop, se devi fare un restore totale usi direttamente 
unsquashfs (o come cavolo si chiama..).
Ciao.
-- 
*** Linux user # 198661 ---_ ICQ 33500725 ***
    ***  Home  
http://www.kailed.net
  ***
        ***  Powered by openSUSE  ***

 unsquashfs (o come cavolo si chiama..).
Il problema e' che il restore dovrebbe essere gestibile da un umano :)
Infatti si tratta di un progetto per nas autocostruito con wol che si 
accende e si spegne con un link sul desktop. E condivide i file con 
samba per poterli recuperare con facilita'.
Poi ci sono i shadow backup, ma a parte.
Ciao ... Dino

Vide wrote:

AFAIK ntfs-3g è pure via FUSE.


Ovvio.


nisba: ho gugolato e pare che il supporto per la compressione 
trasparente in ntfs-3g sia solo parziale. Non puoi fare sovrascrittura 
di file.
"Reading and writing transparently compressed files are supported but 
overwriting is not"
e "deleting" ? :-) certo. rsync e altri tool penso che vadano a 
sovrascrivere, quindi forse non si pone il problema.
E comunque, ad usarlo pesantemente in scrittura avrei qualche timore.


 E comunque, ad usarlo pesantemente in scrittura avrei qualche timore.
Faro' qualche prova.
Ciao ... Dino


Il fatto che debian stable non abbia zfs ma ntfs mi intimorisce un po'.
Ciao ... Dino

 E comunque, ad usarlo pesantemente in scrittura avrei qualche timore.
Non ho capito se lei casi non supportati si ha perdita di dati o meno.
Ciao ... Dino

 Mi tocca usare proprio ntfs anche sotto linux sui dischi di backup?
Sarebbe una scelta stupida perch� ntfs non � un filesystem nato per Unix, 
perch� non � completamente supportato e perch� � comunque un FS cn 
caratteristiche mediamente peggiori degli altri disponibili.
Se vui proprio a tutti i costi utilizzare una compressione a livello di 
filesystem, cosa che comunque continuo a reputare inutile, punterei 
certamente ad uno stackable filesystem in modo tale da poter accedere ai 
dati compressi in modo trasparente ma da poter anche accedervi in formato 
compresso per fare eventuali copie (
p.es
. su nastro) o altre manipolazioni.
Una buona scelta 
p.es
. pu� essere fusecompress che � anche incluso in Debian.
http://miio.net/wordpress/projects/fusecompress/



mmhhh ... provo ad andar di memoria ... le prime versioni di ntfs-3g 
avevano questa limitazione anche quando non si usava la compressione.
Se non ricordo male non riuscivi a sovrascrivere.
Però, effettivamente, non ricordo quale era la reazione.



penso che la ragione vada ricercata altrove: ntfs-3g nei desktop - per 
motivi che puoi intuire - è un MUST. zfs decisamente NO.
Non penso sia un problema di stabilità.
Tieni anche presente che mentre ntfs-3g è reverse-engineered(*) e alcune 
feature sono tutt'ora mancanti, zfs è opensource, e presente solo un 
problema di licenza.
(*) dove "reverse-engineered" = tiriamo un po' ad azzeccare e vediamo se va.




E cosa c'entra? zfs va usato esclusivamente dal *suo* os, ovvero 
OpenSolaris. Altrimenti non ci sono garanzie. Fuse e' un sistema 
grandioso, ma se debbo fare il backup usando un ennesimo layer tanto vale 
fare l'amanuense su nastro di carta perforato. Scommetto che e' piu' 
sicuro.
Ci sono tante persone che hanno fatto fileservers con opensolaris. 
Chi cerca trova.
http://breden.org.uk/2009/06/16/home-fileserver-opensolaris-200906/

 samba per poterli recuperare con facilita'.
Volendo, monti gli archivi il loop all'avvio e li esporti. Nulla di 
complicato. Essendo poi in RO, non c'è nemmeno il rischio di 
cancellazioni accidentali. Puoi anche avere delle partizioni in 
squashfs:
http://www.tldp.org/HOWTO/SquashFS-HOWTO/creatingandusing.html
A me sembra la soluzione più "pulita" se vuoi un fs compresso.


 
http://breden.org.uk/2009/06/16/home-fileserver-opensolaris-200906/
che esperienza hai tu con opensolaris?
uff, la mia esperienza - su macchine virtuali - mi fa ritenere che scala 
verso su, ma scala pochissimo verso il basso.
Ovvero, su un PC comune (non la macchina virtuale), con 2 giga di RAM, 
dischi SATA, ritieni che possa girare bene quanto Linux?


 Poi ci sono i shadow backup, ma a parte.
Cosa intendi per shadow backup?


 Una buona scelta 
p.es
. pu essere fusecompress che anche incluso in Debian.
http://miio.net/wordpress/projects/fusecompress/
Non ho ancora capito che avete contro lessfs.

 Non ho ancora capito che avete contro lessfs.
Io non ho nulla contro lessfs, semplicemente non � un filesystem compresso; 
� un filesystem per la deduplica dei blocchi che ti fa risparmiare spazio ma 
che non comprime.


 Poi ci sono i shadow backup, ma a parte.
qualuno parla di 'fsck' che parte ogni tot riavvi....
Ma il problema è sempre lo stesso. Quando si parte da un punto di vista 
sbagliato, si propone una soluzione sbagliata: ext3
Nessun FS al mondo ha una impostazione di default di questo tipo, e se 
questa è l'impostazione suggerita e predefinita, io qualche quesito me 
lo porrei: perché secondo il mantainer della distro questo FS 
necessiterebbe di un fsck di tanto in tanto?
Non mi si dica che si può modificare l'impostazione con tune2fs, mi si 
dica perché è impostato a quel modo.


 Sei sicuro che XFS supporti il tail merge?
Stavo parlando di JFS
Enrico

 che non comprime.
Ma l'obiettivo di tutto cio` era comprimere o risparmiare spazio?

 Cosa intendi per shadow backup?
Backup completo del fileserver da archiviare.
Ciao ... Dino

 
http://miio.net/wordpress/projects/fusecompress/
Non e' ancora nella stable.
Ciao ... Dino



(open)solaris lo devi imparare, e' un dialetto agli estremi di unix. Ha la 
sua curva di apprendimento abbastanza ripida, non e' roba da poche ore, ci 
vuole tempo.
Dipende dalla tua esperienza quanto ti sara' difficile impararlo.
Su hardware medio - zfs vuole parecchia memoria, meglio 4GB almeno - gira 
piu' che bene. Stara' su un 70% della velocita' di linux, non e' male.

 Su hardware medio - zfs vuole parecchia memoria, meglio 4GB almeno -
Questo è invece un problema :-) Ciò che temevo.



stai fresco: nella stable al massimo ci trovi le coreutils del 1985, 
Metro X server e window maker :-)
passate a Ubuntu server. Mi assumo io la responsabilit� per voi.


 Mi assumo io la responsabilità per voi.
No grazie.

 Ubuntu in Zulu significa "non so usare debian".
ROTFL, ma quoto.
-- 
Professional System & Network Sarcazzer
http://bofhskull.wordpress.com/

 Questo è invece un problema :-) Ciò che temevo.
Anche con i mostruosi aumenti delle memorie 2GB supplementari costano 
davvero poco. Che senso ha fare i pidocchi, specie sul backup?

 Ubuntu in Zulu significa "non so usare debian".
ROTFL. Questa va in sign.



ho un serverotto Atom con un solo banco per la RAM.


 passate a Ubuntu server.
Perchè, le LTS son diverse da debian stable?
Non credo.
E se non parli di LTS, preferisco testing/unstable tutta la vita, davvero.