Btrfs

[dennyv]

Concordo su XFS che è infatti il filesystem che utilizziamo come riferimento. Con reiser ho avuto solo problemi...

[ArtX]

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
Il filesystem dovrebbe essere sacro, non può perdere dati...

[Dcromato]

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.

[Fil9998]

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.

[shodan]

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/it...ds-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...

Comunque urgono test al riguardo... non appena ho tempo mi metto sotto!
Ciao.

[AnonimoVeneziano]

Sarà, ma io non ho mai perso un byte con EXT4 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

Tra l'altro da quando ho scoperto che si può passare da ext4 a btrfs senza formattare mi sta venendo la tentazione ...

[kernelex]

aspettiamo pareri su btrfs

[goldorak]

Originariamente inviato da shodan

.
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...

Che io sappia NTFS non ha il controllo sull'integrita' dei dati, quindi che sia comparabile a ZFS no. Non lo e'.

[dennyv]

Originariamente inviato da shodan

[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

[shodan]

Originariamente inviato da goldorak

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

[shodan]

Originariamente inviato da AnonimoVeneziano

Sarà, ma io non ho mai perso un byte con EXT4 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

Tra l'altro da quando ho scoperto che si può passare da ext4 a btrfs senza formattare mi sta venendo la tentazione ...

Ciao,
se vuoi provare l'ebrezza della perdita dei dati (), 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]

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 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 si capisce come sia assolutamente semplice risolvere tale problema.
Si può:

• 1. Installare Debian su un HDD (usare btfrs e /)
  2. Appena avviato creare il pool e il RAID-1
• 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

  2. 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 [Id 83], 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 questa pagina 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]

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!

[NZ]

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

[zephyr83]

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

[AleLinuxBSD]

Bitrot and atomic COWs: Inside “next-gen” filesystems

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à.

[shodan]

Originariamente inviato da AleLinuxBSD

Bitrot and atomic COWs: Inside “next-gen” filesystems

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]

ma ext4 è ancora nella situazione che ho letto nei primi post oppure dopo 5 anni hanno sistemato i problemi?

[pabloski]

Originariamente inviato da NiubboXp

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.