Bug 801561

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.

If this is happening, this will cause data loss and we should fix it.

Can we reconsider getting this done for 6.4 please?

This request was evaluated by Red Hat Product Management for
inclusion in a Red Hat Enterprise Linux release.  Product
Management has requested further review of this request by
Red Hat Engineering, for potential inclusion in a Red Hat
Enterprise Linux release for currently deployed products.
This request is not yet committed for inclusion in a release.

The proposed approach for detecting cache type works only with SATA drives. And we didn't manage to find an universal way of doing this. In addition, the current approach does not work for any device-mapper drives (like LVM). These are ignored right now.

It looks like we will need to redesign and reimplement this whole feature. I'm not sure if we can afford this for RHEL-6.4 due to low QA capacity.

If we can fix it for S-ATA drives only (not breaking anything else), that would be a very solid improvement and prevent potential data corruption in a very common configuration (laptops and desktops).

Thanks!

I agree with Ric.  Keeping barriers enabled on SATA drives w/ write-back cache would be very valuable incremental improvement, even if it's not a universal solution.  Remember the failure mode here is filesystem corruption, we really need to be sure that our automated tuning scripts will not expose customers to that.

But are you sure it's only valid for SATA drives?  On RHEL5 my san-attached disk has a cache_type and shows "write through":

# cat /sys/block/sdb/device/scsi_disk\:1\:0\:0\:0/cache_type 
write through
# cat /sys/block/sdb/device/model 
RAID 5          
# cat /sys/block/sdb/device/vendor 
DGC     

Why do you say it is only valid for SATA drives?

Is the following sdparm check enough?
# sdparm -g WCE=1 -H DEVICE

(In reply to comment #7)
> In addition, the current approach does not work for any device-mapper drives (like LVM). These are ignored right now.
> 

We could parse the lsblk output to get the matching physical drives.

I'm not a scsi guru but yes, I think sdparm is probably the better way to go (sysfs can be difficult to work with!)

Ok, fair point about software raid over physical devices, that might be work to get to.  I'll ask LVM folks if this is exposed in any simpler way.

$ cat /sys/block/sda/device/scsi_disk/0\:0\:0\:0/cache_type 
write back

shows me the "write back" cache type - not sure if that is easier or harder to parse.

Note we should verify that enterprise luns (iSCSI or FC luns from NetApp, EMC, HP, IBM, etc) show the write through cache type.

(In reply to comment #13)
> $ cat /sys/block/sda/device/scsi_disk/0\:0\:0\:0/cache_type 
> write back
> 
> shows me the "write back" cache type - not sure if that is easier or harder
> to parse.
>
No problem, with scsi_disk, we could get it by simple query.

>Note we should verify that enterprise luns (iSCSI or FC luns from NetApp, EMC,
>HP, IBM, etc) show the write through cache type.
>
Could you help us with it? We have very limited access to HW, only what we can publicly find in Beaker and it can take ages to get the machines from there.

(In reply to comment #15)
> (In reply to comment #13)
> > $ cat /sys/block/sda/device/scsi_disk/0\:0\:0\:0/cache_type 
> > write back
> > 
> > shows me the "write back" cache type - not sure if that is easier or harder
> > to parse.
> >
> No problem, with scsi_disk, we could get it by simple query.
> 
> >Note we should verify that enterprise luns (iSCSI or FC luns from NetApp, EMC,
> >HP, IBM, etc) show the write through cache type.
> >
> Could you help us with it? We have very limited access to HW, only what we
> can publicly find in Beaker and it can take ages to get the machines from
> there.

HP EVA advertises a write-through cache.

(In reply to comment #11)
> (In reply to comment #7)
> > In addition, the current approach does not work for any device-mapper drives (like LVM). These are ignored right now.
> > 
> 
> We could parse the lsblk output to get the matching physical drives.

Proposed bash function to match mount points to physical drives (could be optimised):

function find_disk
{
  TREE=`lsblk -l 2>/dev/null | tac` || return
  LINES=`echo "$TREE" | grep -n " $1\$" | cut -d':' -f1`
  for l in $LINES
  do
    echo "$TREE" | sed -n "$l,$ p" | grep -m1 " disk " | sed 's/^\([^ ]\+\).*/\1/'
  done | uniq
}

Fix committed to upstream repository:
http://git.fedorahosted.org/cgit/tuned.git/commit/?h=1.0&id=64b45e8

This solution can handle LVM volumes on multiple physical devices. Barriers are not disabled in case any of the underlying device has "write back" cache. We can check this only if the device uses SCSI in kernel (SATA, SAN, ...). If we cannot check the cache type, we assume that the barriers can be safely enabled. Barriers are also not disabled on / and /boot partitions.

Resolved in tuned-0.2.19-8.el6

I'm curious, what happens if an explicit "barrier" or "nobarrier" is placed in fstab; does tuned profile enterprise-storage (or default) override it?  I think it does, and I'm not sure it should.  Granted, that may be a separate bug/RFE ...

what do you think?

> I'm curious, what happens if an explicit "barrier" or "nobarrier" is placed
> in fstab; does tuned profile enterprise-storage (or default) override it?  I
> think it does, and I'm not sure it should.  Granted, that may be a separate
> bug/RFE ...

This was not handled by the old code either. And it can be definitively improved. Please, create a different RFE bugzilla for that.

I've connected SCSI disc with Cache mode: writeback in KVM.

  # cat /sys/block/sda/device/scsi_disk/2\:0\:0\:0/cache_type
  write back
  # rpm -q tuned
  tuned-0.2.19-7.el6.noarch
  # tuned-adm profile enterprise-storage
  # mount | grep "/dev/sda"
  /dev/sda on /mnt/test type ext4 (rw,barrier,nobarrier)
  ^ Bug reproduced                            ^

After upgrading the package

  # rpm -q tuned
  tuned-0.2.19-9.el6.noarch
  # tuned-adm profile enterprise-storage
  # mount | grep "/dev/sda"
  /dev/sda on /mnt/test type ext4 (rw)
  ^ bug verified                     ^


I will try to do automatic test later.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0386.html