Linux Today: Linux News On Internet Time.

More on LinuxToday Impact Of Sudden Power Loss On Journalled Filesystems

Jan 19, 2001, 16:56 (4 Talkback[s])
(Other stories by Zack Brown)

WEBINAR: On-demand webcast

How to Boost Database Development Productivity on Linux, Docker, and Kubernetes with Microsoft SQL Server 2017 REGISTER >

"Dr. David Gilbert was unsure whether journalling filesystems were intended to merely survive the occassional improper shutdown, or if users should feel comfortable just powering them down as part of normal operation. Michael Rothwell pointed out that journalling filesystems only guaranteed the consistency of data that had been written prior to shutdown, and that any buffers left unflushed at power-off would be lost, and any applications not properly exited could also do bad things. "Journaling mostly means not having to run FSCK," he said. Daniel Phillips replied to David at greater length:

Welllllll... crashes tend to produce different effects from sudden power interruptions. In the first case parts of the system keep running, and bizarre results are possible. An even bigger difference is the matter of intent. Tux2 is explicitly designed to legitimize pulling the plug as a valid way of shutting down. ... Being able to shut down by hitting the power switch is a little luxury for which I've been willing to invest more than a year of my life to attain. Clueless newbies don't know why it should be any other way, and it's essential for embedded devices. ..."

"Alex Belits strongly disagreed that applications should be considered broken if they mis-handled sudden shutdowns. ... Elsewhere, Stephen C. Tweedie said in response to Daniel's statement that the on-disk filesystem image of journalling filesystems would remain inconsistent until the journal recovery program had run... Alan Cox replied tersely, "Which means an ext3 volume cannot be recovered on a hard disk error." And Stephen replied:

Depends on the error. If the disk has gone hard-readonly, then we need to recover in core, and that's something which is not yet implemented but is a known todo item. Otherwise, it's not worse than an error on ext2: you don't have a guaranteed safe state to return to so you fall back to recovering what you can from the journal and then running an e2fsck pass. e2fsck groks the journal already. And yes, a badly faulty drive can mess this up, but it can mess it for ext2 just as badly."

Complete Story

Related Stories: