View Full Version : Btrfs
AleLinuxBSD
07-10-2010, 19:49
Btrfs Battles EXT4 With The Linux 2.6.33 Kernel (http://www.phoronix.com/scan.php?page=article&item=ext4_btrfs_2633&num=1)
Le performance di questo file system sono così migliorate che esistono perfino rumors che al massimo entro alcune release potrebbe persino essere messo come file system di default.
Tra l'altro questo file system pare non incida sul carico della Cpu, tranne quando viene attivata la compressione, comunque in maniera modesta, portando invece vantaggi in molti test.
Ubuntu Has Plans For Btrfs In 2011, 2012 (http://www.phoronix.com/scan.php?page=news_item&px=ODI0NA)
How We Are Using Btrfs To Find Regressions Incredibly Fast (http://www.phoronix.com/scan.php?page=article&item=btrfs_pts_bisect&num=1)
Discutono di come gli snapshot permessi da questo file system permettono agli sviluppatori di fare check, confronti, ecc, molto più velocemente e di come questa nuova funzionalità permetterà l'ingresso di tante nuove caratteristiche nella suite di benchmark 3.
Io speravo in tux3 (http://tux3.org/), ma benché aveva tutte le caratteristiche per essere un bel file system non c'è stato supporto, il progetto langue, per cui pazienza, l'importante è che esista pure in ambito linux un file system di livello enterprise che possa essere considerato un valido sostituto dell'ext, in modo da potere avere interessanti funzionalità senza dover rimpiangere (spero) zfs (per chi vuole usare zfs in ambiente open probabilmente dovrà rivolgersi su openindiana e/o su freebsd).
AleLinuxBSD
09-10-2010, 07:44
In seguito mi sono messo a fare alcune ricerche un po' più approfondite e penso che questo file system non sia ancora pronto quindi bene fà ubuntu ad aspettare la 12.04 LTS prima di pensare di metterlo come default.
pabloski
09-10-2010, 10:49
In seguito mi sono messo a fare alcune ricerche un po' più approfondite e penso che questo file system non sia ancora pronto quindi bene fà ubuntu ad aspettare la 12.04 LTS prima di pensare di metterlo come default.
e perchè mai? tanto ext4 perde dati come fossero acqua fresca....mi sa che attualmente è più stabile btrfs :D
kernelex
09-10-2010, 15:06
Q8one!
ext4 se magna i dati come fossero noccioline :O
da poco ho riconvertito 2 HDD+1 partizione in ext3.
AleLinuxBSD
09-10-2010, 17:38
Potreste approfondire questo aspetto riguardo ad ext4?
Io l'ho messo adesso per la prima volta, dopo avere aspettato un bel po' di tempo dalla sua uscita, proprio per non avere problemi, nella recente Ubuntu 10.04 LTS e dato che devo aggiornare od installare qualche altra distro pensavo di procedere nello stesso modo, ma se ci sono problemi sostanziali (parlo di adesso e non cose magari accadute in passato), lascio perdere e proseguo con l'ext3.
Parlando di btrfs, dato che non è ancora disponibile la release 1, il formato non è ancora stabilizzato questo significa che possono insorgere incompatibilità con le versioni precedenti, per dire se fate una partizione dati in btrfs condivisa tra più distro, e passa molto tempo ed aggiornate il resto del sistema, i dati potrebbero non essere più leggibili.
Non esistono:
ancora strumenti di check in caso di interruzione della corrente o spegnimenti improvvisi del pc;
strumenti per ridurre le problematiche quando il file system viene riempito;
strumenti grafici per facilitare la gestione degli snapshot.
Purtroppo, a differenza di Zfs, con cui viene sempre paragonato - in quanto sistema similare per funzionalità - non è ancora pronto per ambienti di produzione.
anche io sarei onteressato ai difetti di ext4 :)
pabloski
09-10-2010, 20:18
uno dei problemi è questo http://www.h-online.com/open/news/item/Ext4-data-loss-explanations-and-workarounds-740671.html
kernelex
09-10-2010, 20:20
ho 3 HD sul pc desktop, e capita sempre, se sposto dati da una partizione all'altra, perdo una marea di kb.
stessa cosa quando sposto da laptop a desktop via lan.
jfs > ext4.
come me ne accorgo? tutti i file che sono completi da mesi, li dò nuovamente in pasto al client torrent che gli indica come incompleti al 98-99%.
divfix++ trova errori.
file "presi e visti" mesi fà.
stessa cosa per iso linux.
è mai possibile che, ogni volta che sposto dati già completi, me ne devo ritrovare la metà? :muro:
via lan, i pkg.tar.gz fra desktop e laptop, spesso sono corrotti.
i player mp3 credo che siano più tolleranti, e con questi, nessun segno apparente di corruzione.
cosa accaduta da pochi mesi.
mi ricordo, nella chat di archlinux italia (azzurra.org #archlinux), proprio poco tempo fà, chiedevo lumi.
OT
per 4 anni! ho strappazzato un disco USB da 300GB in fat32 fra linux e win, e mai un problema!
AleLinuxBSD
10-10-2010, 07:29
Mmm.
Non pensavo ci fossero simili problemi anche vedendo come perfino RH 6 avrà come default ext4 (mentre mi pare che dovrebbe mantenere grub 1).
A me installare ext3 al posto di ext4 non cambierebbe una virgola dato che ext4 non dispone di nessuna funzionalità enterprise di mio interesse (purtroppo) quindi non sarebbe un sacrificio però questa cosa, a distanza di così tanto tempo dalla sua introduzione, non mi piace molto. :mbe:
Nota:
Complimenti anche per il link in firma sul cinema asiatico prima o poi ci dovrò buttare un'occhio. ;)
kernelex
10-10-2010, 11:22
appena spostato 561 file per un totale di 14.3 GB da ext3 a ext3.
su circa 3800 parti, ktorrent mi ha dato solo 3 parti mancanti.
se ho voglia, provo a fare ext3 > ext4.
uno dei problemi è questo http://www.h-online.com/open/news/item/Ext4-data-loss-explanations-and-workarounds-740671.html
appena spostato 561 file per un totale di 14.3 GB da ext3 a ext3.
su circa 3800 parti, ktorrent mi ha dato solo 3 parti mancanti.
se ho voglia, provo a fare ext3 > ext4.
grazie delle informazioni :)
però con questa potenziale perdita di dati, etc etc. questo fs porta qualche vantaggio??
cioè perchè è diventato il file system di default?
kernelex
10-10-2010, 12:39
ext3 > ext4 30 parti non scaricate :O
faccio una controprova con ext3 > ext3 :fagiano:
ext3 > ext4 30 parti non scaricate :O
faccio una controprova con ext3 > ext3 :fagiano:
nel tuo caso penso comunque ci sia qualche cos'altro che non vada... dai non è possibile una cosa del genere xD
pabloski
10-10-2010, 13:06
grazie delle informazioni :)
però con questa potenziale perdita di dati, etc etc. questo fs porta qualche vantaggio??
cioè perchè è diventato il file system di default?
ovviamente perchè è molto più veloce e offre funzionalità avanzate utili per i server
kernelex
10-10-2010, 13:24
faccio una controprova con ext3 > ext3 :fagiano:
3 parti non scaricate.
Stiamo scherzando?
Si è vero ext4 aveva ancora qualche bug a metà 2009, oramai abbondantemente fixate anche mediande backporting.
Ora, devi avere qualche problema al dilà di ext4 perché che si mangi dati così nel trasferimento vorrebbe dire corruzione di file e quindi uno scenario impensabile non solo per la produzione intesa in ambiti enterprise, ma anche nell'every day usage.
kernelex
10-10-2010, 19:44
stavo scherzando :sofico:
:mbe:
non è che mi diverto a perdere dati :mbe:
il mio hardware è in condizioni perfette.
ambiti enterprise, bisogna vedere quanti e quali dati spostano quotidianamente.
direi nessuno.
su ext4, finchè non si fa un movimento di file, va tutto molto bene.
ambiti enterprise, bisogna vedere quanti e quali dati spostano quotidianamente.
direi nessuno.
Noi stiamo da un mesetto e passa testando una macchina di backup che ha proprio come filesystem ext4, trasferiamo qualcosa come un terabyte di immagini piramidalizzate al giorno alle quali è associato un hash e fino ad ora non abbiamo mai perso un bit!
La macchina (Dell) ha RHEL 6 Beta con EXt4 e verrà messa in produzione a debita distanza dall'uscita della RH 6 stable.
Visto che la cosa è interessante, invece che torrent, prova a fare un SHA dei file prima di copiarli e, una volta copiati, rigenerarlo per poi confrontarli!
Grazie
Dimenticavo, è un anno e passa che su vari client e laptop utilizzo/iamo ext4 senza aver mai registrato problemi di corruzione file.
goldorak
11-10-2010, 00:40
e perchè mai? tanto ext4 perde dati come fossero acqua fresca....mi sa che attualmente è più stabile btrfs :D
Solo i pazzi di benchmark usano ext 4. Ci sono file system in linux molto piu' sicuri che non ext 4 che e' e rimane un espediente temporaneo fino all'arrivo di btrfs.
xfs, reiser fs, reiser 4 sono i file system da utilizzare.
Va detto pero' che tutti i file system di linux sono fragili, molto piu' fragili di NTFS.
L'uso di un ups e' assolutamente necessario sotto linux per evitare corruzioni al file system dovute ad improvvisi black out. NTFS invece non si corrompe tanto facilmente se ce' un blackout improvviso.
Concordo su XFS che è infatti il filesystem che utilizziamo come riferimento. Con reiser ho avuto solo problemi...
io con XFS mi trovavo bene ma mi dava un piccolo problema nel portatile con un quake3, reiserfs era veloce ma dopo un anno mi iniziava a rallentare pesantemente, invece ext3 è sempre andato bene.
Un peccato era reiser4, che lo hanno iniziato a usare su linux solo dopo avergli tolto non sò quante cose. Questi piallano reiser4 e rilasciano come stabile un fs come ext4 che ha solo problemi :eek:
Il filesystem dovrebbe essere sacro, non può perdere dati...
Dcromato
13-10-2010, 20:12
Io con xfs ho avuto solo problemi mentre jfs non è male ma un po debole se manca corrente...per ora il migliore per me resta ext4.
non mi passa manco per l'anticamera del cervello di usare ext4 per la partizione dati.
anzi ultimamente sto riusando ntfs, sotto linux è lentissimo, bisogna periodicamente deframmentarlo, ma è di una comodità unica e verametne solido, pure scritto da linux.
al nuovo travaso ripasserò il backup dati su ext3.
ext4 lo uso solo per gli OS.
Ciao,
non condivido tutte queste opinioni negative su EXT4, pur premettendo anche io sui sistemi server in produzione uso EXT3.
Il discorso di perdita di dati deriva sostanzialmente dal non utilizzo della funzione fsync da parte della maggioranza delle applicazioni. Il non utilizzo di tale funzione comporta che i dati _non_ vengano scritti immediatamente sul disco, ma solo dopo un certo tempo, che di default su EXT4 è ben 60 secondi.
Perchè i programmi non tendono a non usare fsync? Perchè, su EXT3, la sua implementazione non era il massimo: quanto un'applicazione la invocava, _tutte_ le code dati di _tutte_ le applicazioni erano flushati su disco. Questo spesso comportava un notevole rallentamento del computer.
Proprio per questo motivo (fsync = flush di tutti i dati) EXT3, che sincronizza il journal ogni 3 secondi, in pratica garantisce che ogni 3 secondi tutti i dati vengano scritti su disco, riducendo il rischio di perdita dati. EXT4 invece, supportando il flush dei dati di una singola applicazione, permette al journal di essere flushato su disco ma _non_ sincronizza su disco i dati delle applicazioni. Aggiunto alla possibilità di fare delayed allocation, EXT4 fa più affidamento sulla cache disco e quindi in teoria risulta più esposto a perdita di dati rispetto a EXT3.
Il bello è che, da standard POSIX, il comportamente giusto è quello di EXT4: le applicazioni che devono essere sicure della scrittura sul disco, _devono_ eseguire un fsync o un fdatasync. PostgreSQL, per esempio, di default fa proprio questo.
Comunque, onde mitigare il problema, su EXT4 sono state eseguite della patch che gli pemettono di comportarsi come EXT3 nella maggioranza dei casi "a rischio" di perdita dati. Il link sopra indicato (http://www.h-online.com/open/news/item/Ext4-data-loss-explanations-and-workarounds-740671.html) spiega la cosa più nel dettaglio.
Semmai, una cosa che mi "preoccupa" di EXT4, è il fatto che VirtualBox, quando configurato in modalità AHCI senza buffer di sistema, tende a corrompere le immagini virtuali che girano sul sistema. Devo ancora capire da cosa deriva il problema...
Riguardo a BTRFS, ho visto che in Ubuntu 10.10 è stata implementata la possibilità di sceglierlo come filesystem di root. Devo fare qualche test ;)
Una nota anche su RAISERFS / RAISER4: oltre ai noti problemi del suo creatore (condannato per omicidio), questi filesystem hanno altri problemi e, avendoli usati per anni sulla mia Gentoo box, posso parlare per esperienza vissuta. RAISERFS tutto sommato è abbastanza stabile ma, raggiunta la versione 3.6, il suo sviluppatore ha praticamente "abbandonato" il progetto, per passare allo sviluppo di REISER4, nonostante ci fossero bug importanti. Questo non è piaciuto molto alla comunità di sviluppatori del kernel...
REISER4 invece è piuttosto instabile e più di una volta mi è capitato di perdere tutti i dati della partizione dove lo usavo.
Infine, riguardo a NTFS, per quanto tenda a frammentarsi in modo abbastanza rilevante, lo reputo un _ottimo_ filesystem, dato che supporta compressione on-line, encryption on-line, snapshots e, nelle ultime versioni, anche la delayed allocation. Probabilmente, l'unico filesystem attualmente comparabile a livello di feature è ZFS, che purtroppo su linux non abbiamo... :cry:
Comunque urgono test al riguardo... non appena ho tempo mi metto sotto! :D
Ciao. :)
AnonimoVeneziano
17-10-2010, 11:55
Sarà, ma io non ho mai perso un byte con EXT4 :D Eppure di roba di sviluppo ne installo un mare (kernel e drivers da git e company) e il sistema mi crasha spesso, ma nonostante ciò non ho mai perso nulla.
Saro fortunato :p
Tra l'altro da quando ho scoperto che si può passare da ext4 a btrfs senza formattare mi sta venendo la tentazione ... :asd:
kernelex
17-10-2010, 17:48
aspettiamo pareri su btrfs :fagiano:
goldorak
17-10-2010, 18:29
.
Infine, riguardo a NTFS, per quanto tenda a frammentarsi in modo abbastanza rilevante, lo reputo un _ottimo_ filesystem, dato che supporta compressione on-line, encryption on-line, snapshots e, nelle ultime versioni, anche la delayed allocation. Probabilmente, l'unico filesystem attualmente comparabile a livello di feature è ZFS, che purtroppo su linux non abbiamo... :cry:
Che io sappia NTFS non ha il controllo sull'integrita' dei dati, quindi che sia comparabile a ZFS no. Non lo e'.
[CUT]
Quoto e straquoto!
Giusto per informazione ho cominciato da un paio di giorni a provare btrfs sul notebook (ho il vantaggio che non ho dati importanti in locale :))
Per ora nulla da segnalare
Che io sappia NTFS non ha il controllo sull'integrita' dei dati, quindi che sia comparabile a ZFS no. Non lo e'.
Vero, ma il mio scopo non era quello di recensire un filesystem in due righe, quanto quello di evidenziale che NTFS ha già alcune caratterstiche che invece dovranno essere implementate in molti altri filesystem.
Se vogliamo scendere nel dettaglio, ZFS fa anche data-deduplicazione a livello dei singoli blocchi il che, a mio avviso, lo rende un passo avanti rispetto agli altri filesystem, NTFS incluso. Peccato che in Linux non ci sia...
Ciao. :)
PS: grazie per il link, specialmente i commenti sono molto interessanti ;)
Sarà, ma io non ho mai perso un byte con EXT4 :D Eppure di roba di sviluppo ne installo un mare (kernel e drivers da git e company) e il sistema mi crasha spesso, ma nonostante ciò non ho mai perso nulla.
Saro fortunato :p
Tra l'altro da quando ho scoperto che si può passare da ext4 a btrfs senza formattare mi sta venendo la tentazione ... :asd:
Ciao,
se vuoi provare l'ebrezza della perdita dei dati (:D), prova a creare un file con vim, salvalo e subito dopo resetta il computer col tasto di reset.
Con EXT3 bastano 3 secondi "di vita" al sistema per sincronizzare tutti i dati, mentre EXT4 ritarderebbe molto la scrittura su disco.
Al 90% dovresti avere, al riavvio, il file senza dati dentro... a meno che una patch recente (>6mesi) abbia cambiato le carte in tavola.
Ciao. :)
Likn'_ùs
03-04-2014, 20:45
Mi spiace per il necroBump e per il fatto che siamo nella sezione news,
ma visto che si parlava anni fa di btrfs, e visto che da due giorni mi sto informando e lo sto testando.. voglio condividere i miei pareri qui.. Non ho trovato altre sezioni a riguardo sul forum, ma se i mod ritengono di dover spostare/eliminare, non esistate! ;)
Inutile dire che dal 2010 ad oggi btrfs è migliorato.. L'ho provato su una macchina test:
i5 750
4GB RAM
2xWD Velociraptor 150Gb in RAID-1 software sotto LVM con btrfs..
Ma essenzialmente con tale fs si può eliminare LVM e quindi ho riformattato tutto e rilanciato una nuova installazione..
OBIETTIVO: boottare Debian Jessie Alpha 1 (Testing) con Btrfs che faccia sia da subvolume che da RAID-1.
NOTE:
Kernel 3.13
Durante l'installazione di wheezy 7.4 al momento della formattazione/partizione degli HDD, non è concesso (Partman (http://packages.qa.debian.org/p/partman-base.html) non concede per meglio dire) creare il RAID-1 via btrfs. Per questo stupidamente settai LVM e da lì il RAID-1.
Leggendo però questa pagina (http://danielpocock.com/install-debian-directly-with-btrfs-raid1) si capisce come sia assolutamente semplice risolvere tale problema.
Si può:
Installare Debian su un HDD (usare btfrs e /)
Appena avviato creare il pool e il RAID-1
sempre durante l'installazione spostarsi sulla shell numero 2 (o qualsiasi altra tranne la 4 e la numero 1 logicamente), per fare questo basta premere:
Alt+Fx oppure ALT+frecciette laterali
attivare la console (BusyBox v.1.22.1) e da qui creare il tutto
Io personalmente scelgo il secondo metodo, ed ecco quanto ho fatto:
I miei dischi si presentano come segue:
SCSI12 (0,0,0) (sda) - 150,00GB ATA WD WD1500HLFS-0
SCSI12 (0,1,0) (sdb) - 150,00GB ATA WD WD1500HLFS-0
Inizio il partizionamento creando il 97% dello spazio available come partizione per btrfs e il restante 3% come volume fisico per LVM. Fatto questo per entrambi i dischi vado a creare uno spazio LVM di 9GB per swap. Mi ritrovo quindi con:
LVM VG swapvolumegroup, LV swaplogicalvolume - 9.0 GB Linux device-mapper (linear)
SCSI12 (0,0,0) (sda) - 150,00GB ATA WD WD1500HLFS-0
#1 primary 145.5 GB F btrfs /
#5 logical 4.5 GB K lvm
SCSI12 (0,1,0) (sdb) - 150,00GB ATA WD WD1500HLFS-0
#1 primary 145.5 GB F btrfs /
#5 logical 4.5 GB K lvm
Bene, ora spostiamoci in un'altra shell e accediamo a BusyBox con il comando sh. Qui abbiamo disponibile sia fdisk che quello che a noi serve: mkfs.btrfs.
Iniziamo dando un
fdisk -l
per vedere le partizioni nei dischi.. dovremmo riuscire a vedere sia la partizione del 97% del disco destinata al RAID-1 che faremo tra poco , sia il restante 3% [Id 5] che è stato usato per LVM [Id 8e].
Ora che siamo sicuri di avere due dischi partizionati nel modo corretto, lanciamo l'utility di configurazione del fs btrfs. Nonostante [I]questa pagina (https://btrfs.wiki.kernel.org/index.php/Getting_started) dica che la versione è la 0.19, quella usata in Debian8.0Alpha1 è v3.12.
Per fare il RAID-1 lanciate:
mkfs.btrfs -f -m raid1 -d raid1 /dev/sda1 /dev/sdb1
dove: -m sta per metadata, -d sta per data, -f sta per force, ho dovuto darlo perchè senza quell'opzione mi usciva un errore:
/dev/sda1 appears to contain an existing filesystem (btrfs).
Error: Use the -f option to force overwrite
Al termina del comando l'output è:
WARNING! - BTRFS v.3.12 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using
Turning ON incompat feature 'extref': increased hardlink limit per file to 65536 adding device /dev/sdb1 id 2
fs created label (null) on /dev/sda1
nodesize 16384 leafsize 16384 sectorsize 4096 size 271.08GiB
Btfrs v3.12
Logicamente le grandezze dell'ultima riga di codice dipendono dalla grandezza dei vostri HDD e dalle impostazioni da voi scelte..
EDIT1
Questa procedura sembra non funzionare.. porta all'impossibilità di installare un bootloader..
Provando a settare Btrfs solo sul disco 1 e lasciando il secondo senza partizionamento, e - via shell - creando le partizioni con mkfs.btrfs; creando poi un pool e successivamente il RAID-1 porta lo stesso al medesimo errore.
Provo quindi ad installare Debian sul disco 1 senza RAID-1 e creare il pool e il raid in un secondo momento ad installazione completata.
Aggiornerò il post una volta effettuato il tutto.
Likn'_ùs
04-04-2014, 09:16
Confermo che, installando DebianJessie su un disco con fs Btrfs e poi, al primo avvio - tramite mkfs.btrfs - creare il pool in RAID-1 funziona perfettamente! ;)
di recente ho voluto sperimentare BTRFS su Archlinux
installazione pulita e opzione compress=LZO (quella più veloce) attiva, ebbene:
trasferimento da ext3/4 a BTRFS = 15 MB/s
trasferimento da ext3/4 a ext3/4 = 100 MB/s
ovviamente test effettuato sugli stessi HDD
inoltre una lentezza ESTREMA nell'estrarre un qualsiasi archivio compresso
rimango su EXT4 :D
zephyr83
25-08-2014, 04:05
Finalmente con l'ultima versione di ubuntu (bhe kubuntu) 14.04 si può usare btrfs anche sulla partizione di boot dove c'è grub quindi lo sto usando da un po'! per me è nettamente meglio di ext4, almeno con i file di piccole dimensioni e non mi fa più rimpiangere reiserfs. Non so nello spostamento di grossi file, ma adesso mi sembra decisamente più veloce quando c'è da gestire piccoli file. Con ext4, rispetto a residerfs, notavo rallentamenti anche nel fare un update cn apt-get :doh:
AleLinuxBSD
02-08-2015, 12:47
Bitrot and atomic COWs: Inside “next-gen” filesystems (http://arstechnica.com/information-technology/2014/01/bitrot-and-atomic-cows-inside-next-gen-filesystems/1/)
Giusto per riportare l'attenzione sui benefici nell'uso di file system che dispongano di determinate caratteristiche, non presenti, in modo integrato, nei file system standard moderni.
Considerando pure l'enorme quantitativo di spazio reso disponibile all'utenza da diversi anni, chi non dispone di sistemi molto obsoleti, con risorse troppo limitanti, farebbe bene ad orientarsi su queste soluzioni che, nel caso di linux, significa Btrfs.
Nota:
Non ho ancora approfondito le caratteristiche del diffuso file system XFS che, a partire da RHEL 7 risulta essere stato selezionato come sistema di default, per capire se presenta le medesime funzionalità.
Bitrot and atomic COWs: Inside “next-gen” filesystems (http://arstechnica.com/information-technology/2014/01/bitrot-and-atomic-cows-inside-next-gen-filesystems/1/)
Giusto per riportare l'attenzione sui benefici nell'uso di file system che dispongano di determinate caratteristiche, non presenti, in modo integrato, nei file system standard moderni.
Considerando pure l'enorme quantitativo di spazio reso disponibile all'utenza da diversi anni, chi non dispone di sistemi molto obsoleti, con risorse troppo limitanti, farebbe bene ad orientarsi su queste soluzioni che, nel caso di linux, significa Btrfs.
Nota:
Non ho ancora approfondito le caratteristiche del diffuso file system XFS che, a partire da RHEL 7 risulta essere stato selezionato come sistema di default, per capire se presenta le medesime funzionalità.
Ciao,
l'articolo di arstechnica purtroppo ha un grossolano errore di fondo: non è così che si simula un bit-root! Se ne è discusso parecchio anche sulla mailing linux linux-raid.
In sostanza, quelli di ars hanno:
1) scritto un file (jpeg)
2) modificato, accedendo direttamente al blocco dati e usando un hexeditor, un valore nel jpeg
3) caricato, via filesystem, il file in questione
4) osservato come il file risultava "corrotto".
In realtà, un vero bitroot è un'altrerazione spontanei dei dati, che (ed è questo il punto) ha un'altissima probabilità (10^14, almeno) di essere rilevata e bloccata/corretta dai meccanismi ECC integrati nei settori dei dischi!
Insomma, la possibilità di avere un bitroot "vero" è davvero bassissima, ancor di più usando tecniche di scrub/autopatrol dei dati (cosa che quasi tutti i controller RAID abilitano di default, e che con il software RAID linux e semplicissima).
In sostanza, è molto più probabile che sia la _memoria_ (di sistema, anche ECC, o pure solo quella usata come cache dal disco) a generare errori piuttosto che il disco a non rilevare l'errore.
Non voglio essere fraiteso, però: la validazione tramite hash SHA1/256 ha un valore reale, ed è un peccato che non sia inclusa in ulteriori filesystem (XFS, che uso con grande soddisfazione, non ce l'ha. Si è parlato di integrare qualcosa di simile, ma solo per i metadati). E' solo che le cose non funzionano così come presentate da ars.
Ciao. :)
NiubboXp
21-09-2015, 21:21
ma ext4 è ancora nella situazione che ho letto nei primi post oppure dopo 5 anni hanno sistemato i problemi?
pabloski
21-09-2015, 22:01
ma ext4 è ancora nella situazione che ho letto nei primi post oppure dopo 5 anni hanno sistemato i problemi?
Beh lo uso ogni giorno da anni ormai e funziona benissimo. Dati non ne ho mai persi.
La faccenda del flush era relativa ad una specifica volontà dello sviluppatore di ext4. Non so se sia stato lui a fare dietrofront o gli sviluppatori di software applicativi.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.