Re: CentOS 5.5 does not recognise SAS drives with LSI 1068E Controller

[Les Mikesell <lesmikesell@xxxxxxxxx>]

On 3/10/2011 1:50 PM, John R Pierce wrote:
>
> battery backed writeback caches on raid controllers flush any pending
> data to the disks when power is restored.   if for some reason they
> can't, they flag an error

I know what they are supposed to do - I was just wondering if it happens 
in practice under real-world conditions.

> when an application (such as database server) or file system issues a
> fdatasync or fsync, it expects that when that operation returns success,
> all data has been committed to non-volatile storage.    BBWC exist to
> speed up that critical operation, as actualy committing data to disk is
> slow and expensive.     This is of particular importance to a
> transactional database server, each COMMIT;  has to be committed to disk.

But if you didn't just do the fsync (i.e. you are running just about 
anything but a transactional db), odds are that the directory update 
won't match the data and journal recovery will drop it anyway.

>
> I am intentionally sidestepping the issue of cheap desktop grade storage
> that ignores buffer flush commands as these really aren't suitable for
> transactional database servers unless your data just isn't that
> important.   IDE and SATA stuff has always been 'soft' on this, while
> SCSI, FC, and SAS drives are much more consistent.

I thought there were also problems in layers like lvm that keep the OS 
from knowing exactly what happened.  And a lot of software that should 
fsync at certain points probably doesn't because linux has historically 
handled it badly.

-- 
    Les Mikesell
     lesmikesell@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos