[Linuxtrent] Re: journaling filesystems over RAID

  • From: "Roberto Resoli" <roberto.resoli@xxxxxxxxx>
  • To: linuxtrent@xxxxxxxxxxxxx
  • Date: Fri, 15 Dec 2006 11:41:47 +0100

2006/12/15, Roberto Resoli <roberto.resoli@xxxxxxxxx>:
Ciao a tutti.
Sto cercando di approfondire la questione sui problemi derivanti
dall'installazione di un filesystem journaled su un RAID device (sw o
hw, anche se, mi facevano notare ieri, il RAID è SEMPRE sw).
Sono reduce da una settimana di lavoro per recuperare un disastroso
fallimento di ext3 su RAID5 (e chi ha cercato di usare la rete
wireless della biblioteca la scorsa settimana se ne è accorto) e
vorrei evitare di incorrere in simili disastri in futuro, se
possibile.
Il suggerimento universale (ne accennava anche Marco qualche giorno
fa) è interporre  LVM tra il fs con journal e il RAID, cosa che
osserverò religiosamente d'ora in poi, ma vorrei comunque cercare di
capire meglio i motivi di fondo.

Da quello che ho trovato in rete i problemi derivano dal fatto che i
device RAID possono non soddisfare un prerequisito per l'uso dei
filesystem con giornale, cioè la preservazione del cosiddetto "write
ordering".

Ho trovato un paio di link sulla rete, il primo abbastanza
tranquillizzante (anche se parla di RAID implementato a livello di
kernel, che non è il mio caso):
"Software RAID
In the 2.2 kernels, the software RAID code could write pinned buffers
to disk, which breaks the write ordering constraints used to keep
things consistent. Only drive striping and concatenation were
completely safe, and mirroring was safe as long as you did not use the
on-line rebuild code. In the 2.4 kernels, all software RAID levels
should work properly with the journaled file systems."

Avevo dimenticato il link:
http://www.linuxjournal.com/article/4466

Dalla stessa pagina, un'altra nota molto importante:

"Write Caching

For performance benchmarks, some of the new drives have write-back
caching by default. This means the drive reports a write is completed
before it is actually on the media. The block is still in the drive's
cache, where the writes can be reordered. If this happens, metadata
changes might be written before the log commit blocks, leading to
corruption if the machine loses power. It is very important to disable
write-back caching on both IDE and SCSI drives.

Some hardware RAID controllers provide a battery-backed write-back
cache that preserves the cache contents if the system loses power.
These should be safe to use, but the cache battery should be checked
often. A dramatic performance increase can be seen with these write
caches, especially for log intensive applications like mail servers."

Rob
--
Per iscriversi  (o disiscriversi), basta spedire un  messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx


Other related posts: