ZFS dispone di molte caratteristiche interessanti come l’ultima presentata: zfs deduplication.

Uno dei vantaggi di Zfs è che non necessita di un fsck perché le operazioni su disco sono effettuate in modo che lo stato complessivo del file system sia sempre in uno stato valido. In caso di crash non potrete sapere se sono quelli vecchi o quelli nuovi fino al riavvio, ma i dati saranno consistenti.

Grazie ai checksum che applica a tutti i dati è persino possibile per il filesystem riconoscere dati corrotti e sfruttando la copia di replica evitare di servire dati danneggiati.

In teoria queste ed altre caratteristiche potrebbero evitare la necessità di un programma fsck, ma cosa succederebbe se un filesystem di questo tipo fosse così corrotto da non poter essere montato? Purtroppo nonostante tutte le procedure per cercare di essere insensibile ai problemi hardware si sono già verificati casi come questo ipotizzato.

Questo non vuol dire che il filesystem abbia problemi, anzi ce ne sono altri che sono messi peggio, ma semplicemente che un tool di fsck potrebbe fare la differenza fra la perdita o meno dei dati per un volume zfs corrotto.

Anche Xfs all’inizio si disse che non aveva bisogno di un programma fsck, ma la realtà ha dimostrato che serve ed è servito a molte persone, compreso al sottoscritto.

Chris Mason parlando di Btrfs ha detto in maniera condivisibile quanto scritto sotto. Voi cosa ne pensate?

[..] If you’re sharing duplicate blocks, the owners can have any inode number, and fsck becomes much more complex.

In general, when I have to decide between fsck and a feature, I’m going to pick fsck. The features are much more fun, but fsck is one of the main motivations for doing this work.

Via | OsNews

(2 Voti | Media: 5 su 5)

2 commenti