XFS and nobarriers on Intel SSD

XFS and nobarriers on Intel SSD

[Richard Bade]

[-- Attachment #1.1: Type: text/plain, Size: 1191 bytes --]

Hi Everyone,
I have a question about nobarriers. In the XFS FAQ it looks like the
recommendation is that if you have a Battery Backed raid controller you
should set nobarriers for performance reasons.
Our LSI card doesn’t have battery backed cache as it’s configured in HBA
mode (IT) rather than Raid (IR). Our Intel s3710 SSD’s do have a capacitor
backed cache though.
So is it recommended that barriers are turned off as the drive has a safe
cache (I am confident that the cache will write out to disk on power
failure)?

The reason I am asking about this is that we are seeing some significant
I/O delays on the disks causing a “SCSI Task Abort” from the OS. This seems
to be triggered by the drive receiving a “Synchronize cache command”.
My current thinking is that setting no barriers will stop the drive
receiving a sync command and therefore stop the I/O delay associated with
it.

This is happening on our Ceph storage cluster. For those not familiar with
Ceph, it uses XFS as the underlying filesystem for the object stores.

Has anyone else encountered this issue?
Any info or suggestions about this would be appreciated.

Regards,
Richard

[-- Attachment #1.2: Type: text/html, Size: 1371 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: XFS and nobarriers on Intel SSD

[Eric Sandeen]

On 9/2/15 9:24 PM, Richard Bade wrote:
> Hi Everyone, I have a question about nobarriers. In the XFS FAQ it
> looks like the recommendation is that if you have a Battery Backed
> raid controller you should set nobarriers for performance reasons. 
> Our LSI card doesn’t have battery backed cache as it’s configured in
> HBA mode (IT) rather than Raid (IR). Our Intel s3710 SSD’s do have a
> capacitor backed cache though. So is it recommended that barriers are
> turned off as the drive has a safe cache (I am confident that the
> cache will write out to disk on power failure)?

If you have a device which guarantees that every acknowledged write
will persist even if power is lost, then you can safely turn off
barriers.

> The reason I am asking about this is that we are seeing some
> significant I/O delays on the disks causing a “SCSI Task Abort” from
> the OS. This seems to be triggered by the drive receiving a
> “Synchronize cache command”. My current thinking is that setting no
> barriers will stop the drive receiving a sync command and therefore
> stop the I/O delay associated with it.

Interesting, I thought that usually devices with battery-backed cache
will just ignore synchronize cache commands.
 
But if not, then sure, maybe that's the issue.

-Eric

> This is happening on our Ceph storage cluster. For those not familiar
> with Ceph, it uses XFS as the underlying filesystem for the object
> stores.
> 
> Has anyone else encountered this issue? Any info or suggestions about
> this would be appreciated.
> 
> Regards, Richard
> 
> 
> 
> _______________________________________________ xfs mailing list 
> xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: XFS and nobarriers on Intel SSD

[Eric Sandeen]

On 9/3/15 8:33 AM, Eric Sandeen wrote:
> On 9/2/15 9:24 PM, Richard Bade wrote:

...

>> The reason I am asking about this is that we are seeing some
>> significant I/O delays on the disks causing a “SCSI Task Abort” from
>> the OS. This seems to be triggered by the drive receiving a
>> “Synchronize cache command”. My current thinking is that setting no
>> barriers will stop the drive receiving a sync command and therefore
>> stop the I/O delay associated with it.
> 
> Interesting, I thought that usually devices with battery-backed cache
> will just ignore synchronize cache commands.

Or more precisely, the device should advertise itself in such a way that
the commands wouldn't be sent, even if nobarrier wasn't specified...

-Eric

> But if not, then sure, maybe that's the issue.
> 
> -Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs