Re: [linux-lvm] LVM on SATA/PATA disks

["Stuart D. Gathman" <stuart@bmsi.com>]

On Sun, 13 May 2007, Les Mikesell wrote:

> > Of course, any of the re-ordering (SCSI TCQ, or SATA NCQ) requires
> > filesystem and driver support of write barriers for reliability.
> > Write barriers are not implement in DM, hence LVM, so there is a
> > reliability risk in going with this kind of solution.  Depending on
> > the filesystem this can result in power failures resulting in files
> > having inconsistent data.
> 
> Are you saying that LVM on SCSI is not safe in this scenario?

If out of order writes are enabled, then your server should hold power
to the disk drives for part of a second after disabling further writes
in software.  LVM is a low risk because LVM changes are comparatively
rare, and the modification window is small.  But, theoretically, if
you lost power right at the instant you pressed return on lvcreate,
lvextend, or lvremove, on a system with busy disk io, you could corrupt
the LVM metadata.

Having a UPS and doing a shutdown solves the problem.  However, if your
server enables out of order writes with native queuing, and loses power
without a shutdown, and doesn't keep drives powered long enough after 
stopping the CPUs (this is why high end servers now have a microprocessor
dedicated to power sequencing), then you should not rely on filesystem
journalling, and should do an fsck at reboot.  FS journals rely on physical
writes taking place in-order, or at least having 'sync' calls to finish
previous logical writes before starting a new one (write barrier).
There is a similar issue with creating a database on top of a file.
For example, you have to use 'fsync' after writing a checkpoint, before
beginning updates.

-- 
	      Stuart D. Gathman <stuart@bmsi.com>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.