Re: [linux-pm] Massive ext4 filesystem corruption after a failed s2disk/ram cycle

[Henrique de Moraes Holschuh <hmh@hmh.eng.br>]

On Wed, 04 Nov 2009, KOSAKI Motohiro wrote:
> > On Wed, Oct 07, 2009 at 01:14:10PM +1100, Daniel Pittman wrote:
> > > For what it is worth, I would also be quite interested to know /why/ XFS is
> > > bad in this regard.  Is it just the previously stated "XFS writes to disk
> > > despite freezing kernel threads" issue, or something deeper?
> > 
> > sync pushes out all data to disk, but in a journaling filesystem that
> > might just but the log not the "normal" place on disk.  For a boot
> > loader to deal with it properly it actually needs to do an replay of
> > the log.  Grub does so for reiserfs but not for XFS for some reason.
> > I don't know why problems don't trigger more often with ext3, though.
> 
> I'm sorry for the long delayed and offtopic responce. I discussed this
> issue with okuji-san (GRUB2 maintainer) at several month ago.
> He really wish linux implement real sync.

This is not about real sync.  It is about the box being able to reboot after
a crash or power failure.

GRUB2 is broken in that regard, at least in its peecee-BIOS version:  last
time I checked, it doesn't sort RAID components so that it won't boot from
failed or out-of-sync older components, it can't deal with some of the
filesystems being unclean...

> A bootloader has much constraint than OS (mainly caused by size constraint).
> it can't implemnt jornal log replay logic for _all_ filesystem. Why can't we
> implement storong sync syscall? I don't think this is PM nor bootloader fault.

A bootloader that can't boot a system that went through an unclean shutdown
is quite broken.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh