RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Description of problem:
targetcli set attribute emulate_write_cache=1 is ignored


Version-Release number of selected component (if applicable):
Backstore plugin block v4.1.0-rc2-ml



How reproducible:
Always


Steps to Reproduce:
1. Create a block storage device in targetcli
2. Enter the block device and issue the command "set attribute emulate_write_cache=1"


Actual results:
Parameter emulate_write_cache is now '0'.


Expected results:
Parameter emulate_write_cache is now '1' 
Or an error message stating the reason why the change failed

Additional info:
/> cd backstores/block/TestSan01_block
/backstores/b...stSan01_block> ls
o- TestSan01_block ................................................................ [/dev/sda (136.7GiB) write-thru activated]
/backstores/b...stSan01_block> set attribute emulate_write_cache=1
Parameter emulate_write_cache is now '0'.

The change being ignored is not a bug, I found more information in journalctl.  There should still be more information about why the change was ignored from within the targetcli program.

From journalctl:

Mar 31 10:19:18 testsan01.localhost.local kernel: emulate_write_cache cannot be changed when underlying HW reports WriteCacheEnabled, ignoring request

The kernel code is returning a success error value but printing that message, so there's no way for targetcli to know anything went wrong. We probably want to change the kernel to return an error code (EINVAL) in this case.

I think this is an intended behaviour.

copy pasting from the rtslib library commit b0c41a578bb43db1e787106c2dbc2b46465476a5

    Do not set emulate_write_cache based on write_back param for block
    
    Since the kernel's d0c8b259f (in 3.9+), setting emulate_write_cache for
    block backstores has not done anything -- the kernel now actually uses
    the queue's REQ_FLUSH flag.
    
    No longer set this attribute, but keep the parameter for backwards
    compatibility.

I will close this bug.