Newsgroup: it.comp.os.linux.sys
Titolo: ext3 vs ext4 - stabilità

Ho letto qua e là numerosi problemi di ext4, perdita di dati e simili...
Ma si trattava di forum e bug vecchiotti, che potrebbero benissimo 
essere obsoleti...
Non ho trovato invece notizie recenti.. Voi ext4 lo giudicate stabile 
"davvero", attualmente?
Ricordo svariati anni fa dopo l'introduzione di ext3 avevo fatto prove 
ripetute di unplug, e senza mai un problema...
Da quanto ho letto su ext4, sembra che non sia così robusto...
Ma ripeto, mi interessa la vostra opinione perchè non sono un esperto...

 Da quanto ho letto su ext4, sembra che non sia così robusto...
Lo è tanto quanto ext3.
Lo uso da quando è stato dichiarato stable e ormai anche su diversi server
in produzione e non ho notato alcuna controindicazione e/o instabilità.
-- 
Flavio Visentin
Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

 "davvero", attualmente?
Via. Thread chiuso. ext4 funzia.
cosa ve ne pare invece di btrfs?
Tra 10 giorni esce ubuntu maverick, che includerà btrfs tra i filesystem
di default proposti in fase di installazione (persino la partizione di
boot è già supportata).
Voi lo usereste?
Io ci ho giocato per creare un paio di volumi e ho già scovato il primo
bug:
- crei un volume mirror con (esempio) tre dischi. Spettacolo: con un
  solo comando ti trovi il mirror bello e pronto.
- fai un "df" e ti dirà che lo spazio è quello dei tre dischi sommati
  insieme.
- butti dentro dei file. Fai un df di nuovo e ti accorgi che lo spazio
  occupato dai file è triplo rispetto a quello reale.
In pratica df riporta dimensioni errate....
-- 
Wikipedia Admin: "wikipedia non è un blog"
Iosif Stalin: "i compagni hanno scambiato il partito per un circolo di
discussione"

 Voi lo usereste?
Su Ubuntu no, sul mio PC invece lo uso anche già adesso per roba poco
importante.


 cosa ve ne pare invece di btrfs?
Io lo uso sul backup server con backuppc, e fino ad ora non mi ha dato 
alcun problema (toccata d'obbligo)
Enrico

 hanno tantissimi files piccoli
questa è una questione che non avevo considerato.
Aggiungo altri elementi invece.
- compressione trasparente.
- tutte le operazioni si fanno online: shrink, grow, aggiunta/rimozione
  di device.
- la creazione/gestione dei volumi è assolutamente idiot-proof, come
  in zfs(*)
- cloning (sarebbe lo snapshot writable)
- checksum dei dati
Manca, ed è "planned"
- deduplica
- raid5 e raid6 
Per finire, scopro adesso che, non solo ubuntu lo usa ma anche:
Red Hat Enterprise Linux e MeeGo
E un conto è Fedora, un altro conto è Red Hat Enterprise. Se red hat si
azzarda a proporlo ai clienti enterprise, vuol dire che qualche
passo avanti è stato fatto.
(*) da provare. se prima facevate: fdisk, crea partizione, assegna id,
mdadm --create blabla, pvcreate ..., vgcreate ...., lv create, adesso
farete semplicemente:
mkfs.btrfs -L miopool -m raid1 -d raid1 /de/sdxx /dev/sdyy /dev/sdzzz
dove /dev/sd... può essere indifferentemente una partizione o un
device, senza bisogno di creare inutili PV, inutili VG, inutili id alle
partizioni.... come su ZFS, è tutto trasparanete e se lo smazza lui
"internamente".


 ha scritto:

Leggevo adesso che pure redhat 6 lo propone tra i FS di default....
mah... sarà giunto il momento di cambiare?
Per il momento ci ho giocato solo sulle macchine virtuali.


 Enrico
Ciao,
Michele


df, quando visualizza fs btrfs, riporta spesso informazioni errate.
Anche qui, nella ml, ci sono decine di messaggi a riguardo e relative
spiegazioni a riguardo.
Michele


Io ho installato ieri un Ubuntu server con ext4 ( per la prima volta ).
Quello che mi ha stupito è la velocità nel boot .. veramente figo!
-- Yena --

 limite definito nel formato del disco.
Se quello che dici è vero, e non ne dubito, allora anche l'utilizzo come 
storage di mailbox o su un server di posta sono da sconsigliare.
Sia dovecot che postfix usano pesantemente gli hardlinks rispoettivamente 
per maildir e per la spool.
Mentre sul primo (dovecot) gli hardlinks si possono disabilitare con 
perdita di prestazioni, sul secondo no.
Questo lo rende per i miei scopi abbastanza limitato.

 Questo lo rende per i miei scopi abbastanza limitato.
Spero che decidano di cambiare questa limitazione (con conseguente
cambio di formato) prima della messa in stable del codice. Chissà!
Ciao


La limitazione è di 256 hard link *nella stessa directory*, limite che
sebbene in certe circostanze possa essere basso è comunque da riconoscere
che è veramente rarissimo che questa evenienza si verifichi.
Il limite di hard link su dir diverse è (IIRC) di 64K, ampiamente
sufficiente per backuppc nel 99.99999% dei casi ed in linea con gli altri FS.


 "internamente".
Interessante e comodissimo, e invece per la gestione? Tipo 
togliere/riparare/ecc?
Hai un "tutorial" o documenti da consigliare?

 - raid5 e raid6
Manca anche la gestione delle quota per i subvolume, altrimenti non ne 
vedo il senso di esistere
Enrico

 ha scritto:

mmhh.. la documentazione è work in progress per il momento. Quel poco
che c'è qui 
https://btrfs.wiki.kernel.org/
 che ti spiega come
aggiungere rimuovere. 
e le man pages.
Comunque, togliere/riparare, dopo averci preso un po' la mano, sono cose
semplici.
Ci sono cose che devo ancora imparare a fare.
In LVM c'è il layer dei VG ed il layer dei LV. Questo ti consente di
creare un numero elevato di LV, su un layer astratto rispetto a quello
delle partizioni.
Se non sbaglio con ZFS lo ottieni creando Volumi all'interno dei pool
ed assegnandogli delle quote.
In BTRFS invece si creano subvolume, e gli si assegna una quota.... ma
non so come per il momento.


 On Thu, 30 Sep 2010 17:25:32 +0000, Max_Adamo wrote:

mi fai un refresh sulla questione quote dei subvolume? Ne avevamo
parlato ma non mi ricordo esattamente i termini.
Ti dico questo perché in questo istante leggo la seguente info:
Subvolumes can be given a quota of blocks, and once this quota is
reached no new writes are allowed.
Forse è una aggiunta recente... non saprei. Ma era questa la cosa della
quale stavamo parlavando?


Il giorno Fri, 01 Oct 2010 12:22:47 +0200
Michele Petrazzo <michele.petrazzo@REMOVE_me_unipex.it> ha scritto:

Non vorrei dire una gran cacchiata, ma mi pare che con il kernel 2.6.35
dovrebbe essere già stable (altrimenti non mi spiegherei l'introduzione
in redhat enterprise)
I bug/problemi dei quali parli, a quale kernel fanno riferimento?


 ha scritto:

mmhh ... reiser era un attimo lento in fase di mount (mo' mi sfugge il
motivo) ma la velocità del boot dipende da altre cose.
maverick fa il boot ancora più velocemente di lucid, ma questo dipende
dal fatto che ormai hanno finito di "upstartizzare" la quasi totalità
dei servizi.
Fino alle versioni precedenti, upstart c'era, ma la maggior parte dei
servizi erano ancora su sysv.
p.s.: due tra quelli che sono ancora rimasti li ho creati io in questi
giorni e li ho inviati su launchpad per essere passati su upstart.


 On Thu, 30 Sep 2010 19:11:44 +0000, Max_Adamo wrote:

ok scusami per non averti letto prima da questa parte.
Ti re-incollo qui il messaggio:
https://btrfs.wiki.kernel.org/index.php/Btrfs_design
 
Subvolumes can be given a quota of blocks, and once this quota is
reached no new writes are allowed.
Pare che questa feature adesso ci sia.


 in produzione e non ho notato alcuna controindicazione e/o instabilità.
OK...
Un'ultima domanda:
qualcuno ha avuto esperienze di "unplug brutali", ad esempio blackout 
senza ups?

 senza ups?
Hai voglia!!! :-) Lo uso di default sul portatile che tra esperimenti e mia
idiozia ne supporta di ogni.


 On 09/30/2010 07:14 PM, THe_ZiPMaN wrote:

Io.
L'altro giorno è andata via la corrente.
Ho riacceso.
Dopo 5 minuti è tornata la correte e il PC - coma da impostazione nel
BIOS - si è acceso da solo.
Dopo qualche minuto la corrente è saltata nuovamente.
A quel punto ho staccato il cavetto e ho riacceso più tardi.
Non è successo nulla di nulla.


 ha scritto:
Scusate per il morphing involontario!



OK..
Grazie mille a tutti !!

 normali utenti non vengono considerati.
too much beaf on the fire? ^__^
Non voglio giustificare nessuno, però, nel bene e nel male, c'è stata
l'esplosione dei lamerozzi che usano linux. 
Questo ha fatto si che la quantità di bug aperti sia cresciuta in
maniera esponenziale. Ci sono una marea di bug riportati male, che
però devono essere controllati uno per uno dagli sviluppatori, per poi
essere marcati invalidi, duplicati, won't fix, missing information ...
e il bug, quello importante, finisce per rimanere coperto da tutti gli
altri.


 
C'è. 
per impostare la quota:
btrfs filesystem resize 10g /pool1/svol1
per annullar la quota:
btrfs filesystem resize max /pool1/svol1
http://www.seedsofgenius.net/uncategorized/zfs-vs-btrfs-a-reference


 
http://www.seedsofgenius.net/uncategorized/zfs-vs-btrfs-a-reference
BtrFS: currently, btrfsck can only identify errors, not correct them. 
Similarly, checksum inconsistencies are flagged, but not repairable. 
Rebalancing may help in some cases
Direi che a questo punto ancora non si possa dire di poter usare 
profiquamente Btrfs (personalmente, proprio per questi motivi, ho 
preferito rifare il file system del backup server in LVM+ReiserFS)
Enrico

 On Fri, 01 Oct 2010 23:16:18 +0000, Max_Adamo wrote:

Hai fatto bene a prescindere. Io non so se i tempi sono veramente
maturi per Btrfs.
Però, quel sito al quale fai riferimento, citando problemi e bug, dice:
This table was generated using Btrfs v0.19, included in the 2.6.33
kernel shipped with Fedora 13.
Btrfs è considerato "stabile" (non so nemmeno da chi) nel kernl 2.6.35


 Btrfs è considerato "stabile" (non so nemmeno da chi) nel kernl 2.6.35
Da quello che leggo sul sito, la struttura dell'ODS e` considerata 
stabile dal 2.6.31
Enrico

 On Sat, 02 Oct 2010 13:18:09 +0000, Max_Adamo wrote:

p.s.: il resize dei subvolume c'è sulla carta ma a me non funziona. Se
do un resize al subvolume se lo becca tutto il filesystem (a prescindere
che il 'df' da informazioni sbagliate, mi pare che non funzioni come
dovrebbe).


 Btrfs è considerato "stabile" (non so nemmeno da chi) nel kernl 2.6.35
Nel kernel 2.6.36-rc6 è ancora marcato come "experimental".
-- 
"Inside my shell, I wait and bleed..."
(Slipknot)
http://med.homelinux.org/spooky

 
e lo fanno uscire su Red Hat Enterprise? E' questo che non capisco.
Passi per Ubuntu, che in questo caso non è una LTS, e passi per MeeGo.
IMHO è incompleto piuttosto che instabile. Il che lo rendo poco usabile
in certe circostanze.
Vero è che - scopro adesso - che si può usare il 'df' integrato di
btrfs "btrfs filesystem df /blabla", ma che me ne faccio di Nmila
sottovolumi se lo spazio non è gestito separatamente.
Approfitto invece per puntualizzare che potrebbe non essere vero che
gestisce male lo spazio con file piccoli. Viene usata una tecnologia
per il packing dei file piccoli all'interno dello stesso blocco,
finalizzata proprio a riempire il più possibile.


 in redhat enterprise)
  No, non lo è:
~/src/linux-2.6.35.7 $ make menuconfig
File systems  ---> < > Btrfs filesystem (EXPERIMENTAL) Unstable disk format
 < Help >
CONFIG_BTRFS_FS:
Btrfs is a new filesystem with extents, writable snapshotting, support
for multiple devices and many more features.
Btrfs is highly experimental, and THE DISK FORMAT IS NOT YET FINALIZED.
 You should say N here unless you are interested in testing Btrfs with
non-critical data.
To compile this file system support as a module, choose M here. The
module will be called btrfs.
If unsure, say N.
  Ciao,
-- 
Alessandro Selli 
http://alessandro.route-add.net
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.

 FINALIZED. 
Vedi che non sbagliavo? Non ero ancora arrivato qui mentre rispondevo
sopra. FINALIZED era l'accezione più corretta.


 un momento all'altro.
  Avevi chiesto se il btrfs fosse stabile.  La risposta è: no, non lo è.
 Il che non ha a che vedere con il fatto che vada in crash quante volte
- in che circostanze - su che piattaforma - in che configurazione -
sotto che carico ecc.  Ha a che vedere con il fatto che non è stabile
perché, per lo meno, non lo è il suo formato.  Non è stabile in quanto è
"altamente sperimentabile", in quanto è da usarsi se si è "interessati
al suo sviluppo su dati non critici" e che altrimenti non lo si dovrebbe
includere nei driver da compilare.


  Non è stabile in quanto è "altamente sperimentabile",
  Vabbé, s'è capito :-)


 dovrebbe includere nei driver da compilare.
Questo è il modo in cui lo sto utilizzando io al momento. Lungi da me
usarlo per scopi più seri (nonostante la gui di installazione di Ubuntu
me lo proponeva anche per la partizione di boot).


 in certe circostanze.
Sul sito mettono la mani avanti dicendo che "Btrfs is under development..."
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/Adding_Partitions-x86.html
Per usarlo bisogna passare al boot il parametro "btrfs" altrimenti
l'installer non prevede la possibilità di utilizzarlo nemmeno tramite il
partizionamento manuale.
In questo modo hanno accontentato tutti:
- l'amministratore meno esperto non rischia di utilizzarlo per sbaglio
- il sistemista smanettone può testarlo, magari su macchine non di
produzione


 finalizzata proprio a riempire il più possibile.
E` il tail packing (o block suballocation) implementato anche in ReiserFS
Enrico


O non è attiva di default (cosa che non mi risulta) o non funziona.
Tar di un FS reiserfs di backuppc riversato su un btrfs più grande del 20%
rispetto all'originale ed ha comunque esaurito lo spazio. Quindi sorry ma
per il momento non se ne parla.


 
IMHP il tuo problema dovrebbe/potrebbe essere il seguente:
$ btrfs filesystem df /lxc
Data: total=3.01GB, used=1.98GB
$ df -h /lxc
File system            Dim. Usati Disp. Uso% Montato su
/dev/sdc5             102G  2,4G  100G   3% /lxc
La differenza è circa il 20%. Ma è 'df' che riporta info sballate
(come già detto nel thread).
p.s.: questi comandi esistono solo nell'ultimissima versione dei tool.


> IMHP il tuo problema dovrebbe/potrebbe essere il seguente:
No, si è proprio fermata la copia con errore di disk full.


 altri FS.
Parlo per aver letto di molti e non per aver provato (ancora), ma se
mettessi un semplice rsnaphost (che sfrutta gli hard link) che mi
facesse la copia della home di un server in produzione qualsiasi, ad
occhio questo limite lo supero in un batter d'occhio:
srv-produzione:/home# find ./  -type f | wc -l
287634
Considerando che, per un server di backup, tengo in linea 10/15 gg di
dati e N backup al giorno, si fa presto a vedere quanti hard link
possono essere generati in quel fs.
Diverso è se anziché usare rsnaphost usassi la gestione degli snapshots
integrata, questo limite non si porrebbe, ma btrfs non è quindi da
considerarsi un fs general-purpose e sostituto di ext
Michele

 possono essere generati in quel fs.
10/15 per file :-)


 O non è attiva di default (cosa che non mi risulta) o non funziona.
non saprei dirti, secondo Wikipedia Btrfs e` uno dei file system che 
implementa il block suballocation (assieme a ReiserFS, JFS e UFS2)
Enrico

 THe_ZiPMaN wrote:

il problema, ad essere onesti, è che PER IL MOMENTO con btrfs non si
distingue mai quel che si può fare adesso, da quel che si potrà fare in
futuro.
A proposito di quell'altro discorso, leggevo sempre sulla wiki "è
possibile assegnare una quota a ciascun sottovolume".
Effetivamente il comando eseguito sul sottovolume non da errore. Peccato
poi che la quota venga allocata per l'interno volume.
