Barriers and journaling filesystems [LWN.net]

Barriers and journaling filesystems

Posted May 22, 2008 10:29 UTC (Thu) by perrymg (guest, #39684)
Parent article: Barriers and journaling filesystems

"if the commit record gets written first, the journal may be corrupted."

Would placing the Journal into its own mirrored device suffice?
(Assuming of course that only one mirror could fail at a time.)

Wouldn't a mirrored Journal perform faster on (re)mount, especially if journal_data was in
use? 

For LVM an LV has the option to be mirrored (as well as striped), could a separate mirrored LV
be used just for the Journal to avoid concerns about the lack of barriers on LVM?

(Log in to post comments)

Barriers and journaling filesystems

Posted May 22, 2008 13:35 UTC (Thu) by perrymg (guest, #39684) [Link]

I do see that a Linux system crash would still cause the Journal to become corrupted, mirrored
Journal or not. Just 2 copies of a bad Journal at the point in time of the crash!

But for disk related errors, mirroring at least the Journal would seem to make sense to me.
Mirroring the whole disk would achieve the same thing, but obviously more data would have to
be mirrored.

I guess for Enterprise level users all disk would be in RAID arrays and hence their only real
fear is that of a Linux system crash.

Barriers and journaling filesystems

Posted May 22, 2008 13:50 UTC (Thu) by perrymg (guest, #39684) [Link]

Sorry for the multiple posts, but this topic is fascinating and important.

If enabling barriers has a performance impact, then putting the Journal onto a separate disk
with barriers enabled (Mirrored or not), and leaving the FS data on a disk with barriers
disabled may be a short term compromise for some users?