On Linux, XFS is preferred. Noop or Deadline, not CFQ is preferred.
I don't know if any of this has any impact on the crash you describe.
I am quite suspicious of VMs.
> -----Original Message-----
> From: Andrew Miklas [mailto:andrew@stripped]
> Sent: Thursday, October 04, 2012 3:21 PM
> To: Rick James
> Cc: Manuel Arostegui; mysql@stripped
> Subject: Re: InnoDB corrupt after power failure
> Hi Rick,
> On Oct 4, 2012, at 2:40 PM, Rick James wrote:
> > I hope you turned OFF caching on the drives, themselves. The BBU
> should be the single place that caches and is trusted to survive a
> power outage.
> The DB server in question is running in a virtualized environment, so
> the array shows up as a SCSI device inside our VM. I can't use hdparm
> to directly check whether the disks are doing write caching, but our
> hosting provider assures us that once data is sent to the virtual SCSI
> device from inside the VM, it will be persisted to disk even if there's
> a power failure.
> I'm a bit suspicious of a recent change we did to switch our ext3
> journals from data=ordered to data=writeback. The ext3 docs say "a
> crash+recovery can cause incorrect data to appear in files which were
> written shortly before the crash" . As a result, if a tablespace
> were extended just before the power failure, it might be possible that
> when MySQL restarts, it will see random data at the end of the
> tablespace. It seems like this could happen even if the disks are BBU
> / not write caching, because the increase of the ibd's file size in the
> inode and the zeroing out of the new blocks assigned to the file are
> not atomic with respect to one another.
> Is the InnoDB recovery process OK with this scenario? Has anyone else
> seen corruption problems with data=writeback?
> -- Andrew
>  http://lxr.linux.no/linux+v3.5.2/Documentation/filesystems/ext3.txt