Bug 838759

Summary: [FCoE TGT] Fileio dont' check duplicate storage object creation. Need open with O.EXCL
Product: Red Hat Enterprise Linux 6 Reporter: Gris Ge <fge>
Component: python-rtslibAssignee: Andy Grover <agrover>
Status: CLOSED ERRATA QA Contact: Gris Ge <fge>
Severity: high Docs Contact:
Priority: high    
Version: 6.3CC: ddumas, tlavigne
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: python-rtslib-2.1.fb21-1.el6, fcoe-target-utils-2.0rc1.fb16-3.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-21 10:54:44 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 840683    

Description Gris Ge 2012-07-10 02:34:37 UTC
Description of problem:
It's wrong to allowed 2 fileio storage object pointing to same fileio.
====
|   o- lun4 [fileio/disk20120705163234204805 (/tmp/lun_4_testabc)]
|   o- lun5 [fileio/disk20120705163722400445 (/tmp/lun_4_testabc)]
====

Need O.EXCL.

Version-Release number of selected component (if applicable):
RHEL 6.3 GA
fcoe-target-utils-2.0rc1.fb10-5.el6.noarch

How reproducible:
100%

Steps to Reproduce:
1. Execute this command twice:
targetcli /backstores/fileio create $disk_name $lun_name ${size_bytes}B
2.
3.
  
Actual results:
2 fileios pointing to same file.

Expected results:
fcoe-target-utils should warn and fail to create duplicate storage object.
Same rule should also applied to block and pscsi backstore types.

Additional info:
beta blocker requested as this bug will cause data corruption if 2 storage objects mapped hosts but with same data file.

Comment 1 Gris Ge 2012-07-10 05:16:38 UTC
The same thing also happen to LUN Mapping:
=====
    o- 20:00:00:1b:21:59:12:37 . [enabled]
      o- acls .. [1 ACL]
      | o- 10:00:00:05:1e:8f:fa:da ......... [3 Mapped LUNs]
      |   o- mapped_lun0 ......... [lun0 fileio/disk20120709141129331401 (rw)]
      |   o- mapped_lun1 ......... [lun0 fileio/disk20120709141129331401 (rw)]
      |   o- mapped_lun2 ......... [lun0 fileio/disk20120709141129331401 (rw)]
      o- luns .. [1 LUN]
        o- lun0 ....... [fileio/disk20120709141129331401 (/tmp/lun_4_testabc)]
=====

Please fix it also.

Comment 7 Gris Ge 2012-11-30 05:00:34 UTC
Still got 
===
      o- luns ................... [2 LUNs]
        o- lun0 ......... [fileio/disk1 (/tmp/fcoe-lun1)]
        o- lun1 ......... [fileio/disk1 (/tmp/fcoe-lun1)]
===
in fcoe-target-utils-2.0rc1.fb16-2.el6.noarch

For MapLUN and fileio, duplication check works well:
===
/> /tcm_fc/20:00:00:1b:21:59:12:37/acls/20:00:00:10:18:88:e9:4b create 0 1
This MappedLUN already exists in configFS.
/> /backstores/fileio create disk1 /tmp/fcoe-lun1 10240M
Using params size=10240M write_back=True sparse=True
storage object for /tmp/fcoe-lun1 already exists
===

Since duplication check for this command is not fix yet:
====
/tcm_fc/20:00:00:1b:21:59:12:36/luns/ create /backstores/fileio/disk1
====

I am assigning this bug back for further work.

Comment 13 Gris Ge 2013-01-04 08:25:29 UTC
Fixed in fcoe-target-utils-2.0rc1.fb16-3.el6.noarch
===
/> /tcm_fc/20:00:00:1b:21:59:12:37/acls/20:00:00:10:18:88:e9:4b create 0 1
This MappedLUN already exists in configFS.
/> /backstores/fileio create disk1 /tmp/fcoe-lun1 10240M
Using params size=10240M write_back=True sparse=True
Created fileio disk1 with size 10737418240
/> /backstores/fileio create disk1 /tmp/fcoe-lun1 10240M
Using params size=10240M write_back=True sparse=True
storage object for /tmp/fcoe-lun1 already exists
/> /backstores/fileio create disk1 /tmp/fcoe-lun1 10240M
Using params size=10240M write_back=True sparse=True
storage object for /tmp/fcoe-lun1 already exists
/> /tcm_fc/20:00:00:1b:21:59:12:36/luns/ create /backstores/fileio/disk1
Created LUN 3.
/> /tcm_fc/20:00:00:1b:21:59:12:36/luns/ create /backstores/fileio/disk1
lun for storage object /backstores/fileio/disk1 already exists
====

verify.

Comment 15 errata-xmlrpc 2013-02-21 10:54:44 UTC
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-0466.html