[Linuxtrent] Re: ext3 + power failure = filesystem corrotto
- From: "Roberto Resoli" <roberto.resoli@xxxxxxxxx>
- To: linuxtrent@xxxxxxxxxxxxx
- Date: Mon, 22 Dec 2008 08:50:27 +0100
2008/12/21 Flavio Stanchina <flavio@xxxxxxxxxxxxx>:
> Roberto Resoli wrote:
>>
>> Una cosa che ho trovato su wikipedia, ext3 montato con le opzioni di
>> default non protegge affatto (anzi, causa lui stesso) corruzioni in
>> caso di crash improvvisi, ad esempio a causa di cadute di
>> alimentazione.
>>
>> Il problema è risolvibile abilitando l'opzione barrierrs, che però non
>> funziona su LVM o RAID sw.
>>
>> http://en.wikipedia.org/wiki/Ext3#No_checksumming_in_journal
>
> Dall'articolo su Wikipedia:
> ... and if the hardware is doing out-of-order write caching, ...
>
> Io non so chi sia stato il genio a pensare che fare write caching fosse una
> buona idea, ma di certo se non hai un controller RAID con cache a batteria
> bisogna disabilitarlo.
Sicuramente risolve, ma credo che disbilitare il write caching
penalizzerebbe moltissimo le prestazioni, che è anche il motivo per
cui le barriers sono disabilitate di default; dall'articolo di LWN:
"Andrew Morton's response tells a lot about why this default is set
the way it is:
Last time this came up lots of workloads slowed down by 30% so I
dropped the patches in horror. I just don't think we can quietly go
and slow everyone's machines down by this much...
There are no happy solutions here, and I'm inclined to let this dog
remain asleep and continue to leave it up to distributors to decide
what their default should be. "
A quanto pare solo SUSE abilita di default le barriers su ext3.
Tra l'altro avere le barriers abilitate sembra sia assai più
performante che disabilitare il caching; dice Chris Mason:
http://kerneltrap.org/mailarchive/linux-kernel/2008/5/19/1872444
"Barriers are actually really fast, at least when you compare them to running
with the writecache off."
Per fortuna, il reordering avviene abbastanza raramente, perchè il
giornale viene solitamente creato contiguo; sempre dall'articolo di
LWN:
"Ted Ts'o explains what's going on: the journal on ext3/ext4
filesystems is normally contiguous on the physical media. The
filesystem code tries to create it that way, and, since the journal is
normally created at the same time as the filesystem itself, contiguous
space is easy to come by. Keeping the journal together will be good
for performance, but it also helps to prevent reordering. In normal
usage, the commit record will land on the block just after the rest of
the journal data, so there is no reason for the drive to reorder
things. The commit record will naturally be written just after all of
the other journal log data has made it to the media. "
Per quanto riguarda la cache a batteria, qui ce l'abbiamo, ma se si fa
un destroy di una virtual machine xen non è di nessun aiuto.
Basta non farlo, direte, ma ci sono casi in cui fare destroy è l'unica
opzione; ad esempio quando ci sono processi in "uninterruptible sleep"
(stato D in ps).
ciao,
rob
>
> --
> Ciao, Flavio
>
> Those who do not understand Unix are condemned to reinvent it, poorly.
> -- Henry Spencer
> --
> Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
> "subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx
>
>
>
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx
Other related posts: