Re: zFCP /dev naming
Correction, LinTel does prefix WWN with 0x but not LUN: pci-:06:00.0-fc-0x500507680b327632-lun-1 -> ../../sdd Neale -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: /etc/mtab and "df -h" problem
> > Redhat support found a reason - a bug it glibc which was fixed just a > couple of weeks ago > > It has been fixed in glibc-2.12-1.209.el6_9.1 Thank you for your suggestions regards Gregory -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: /etc/mtab and "df -h" problem
Redhat support found a reason - a bug it glibc which was fixed just a
couple of weeks ago
2017-04-19 21:15 GMT-04:00 Grzegorz Powiedziuk :
> Reboot didn't resolve the issue. I will have to open a ticket with redhat.
> hopefully they can figure this out
> Gregory
>
> 2017-04-18 23:31 GMT-04:00 Grzegorz Powiedziuk :
>
>> 2017-04-18 16:34 GMT-04:00 Alan Altmark :
>>
>>> On Monday, 04/17/2017 at 03:14 GMT, Grzegorz Powiedziuk
>>> wrote:
>>> > I am having a really weird issue on one of the z redhat systems.
>>> Probably
>>> > it doesn't have anything to do with Z but we have some great minds here
>>> so
>>> > perhaps someone will help me
>>> >
>>> > the "df -h" or "df -P" command doesn't work when run as a normal user.
>>> > "df" on it's own works fine.
>>> >
>>> > Error:
>>> > df: cannot read table of mounted file systems: Permission denied
>>> >
>>> > Now, here is when it gets really strange. Above suggests wrong
>>> permissions
>>> > on /etc/mtab which are fine:
>>> > [root@it069qz5ora lib64]# ls -la /etc/mtab
>>> > -rw-r--r-- 1 root root 2024 Apr 17 10:44 /etc/mtab
>>> >
>>> > But the "df -h" is trying to open that file with WRITE access mode !!!
>>> > strace df -h 2>&1 |grep open | grep mtab
>>> > ...
>>> > open("/etc/mtab", O*_RDWR*|O_CLOEXEC) = -1 EACCES (Permission
>>> denied)
>>> >
>>> > On all other systems"df -h" opens that mtab file in O_RDONLY. Why this
>>> one
>>> > is different?
>>> >
>>> > And as I said, regular "df" works fine and it usies O_RDONLY flag.
>>> >
>>> > So the problem happens only with "df -h" or "df -P" . That doesn't make
>>> any
>>> > sense to me.
>>> >
>>> > Has anyone seen anything like that?
>>>
>>> Weird. The read_file_system_list() routine in mountlist.c (called by
>>> df.c) code shows a hard-coded "r" option in the fopen(), and I don't see
>>> df calling some other "mount list" function because of -h or -P.
>>>
>>> Alan Altmark
>>>
>>
>>
>> I know .. doesn't make sense. Thanks for looking into source code. I
>> wonder if something has change in the code in the
>> newer versions of this package. Tomorrow in the evening I will reboot
>> this guy. Hopefully this will fix it.
>>
>> Aha, forgot to say. I've changed permissions of mtab file to 666 for a
>> moment just to make sure that this is the problem and of course it worked
>> this time.
>>
>> Gregory
>>
>>
>
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
KVM on z Knowledge Series: Disk Performance Hints & Tips
See http://kvmonz.blogspot.com/p/knowledge.html for the second entry in our "knowledge" series about disk performance hints & tips with KVM on z. The first entry providing guidance on configuration is available at http://kvmonz.blogspot.co.uk/p/blog-page_7.html Mit freundlichen Grüßen / Kind regards Stefan Raspl KVM on z Systems IBM Systems & Technology Group, Systems Software Development / SW Linux on System z Dev & Service --- IBM Deutschland Research & Development GmbH / Vorsitzende des Aufsichtsrats: Martina Koederitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: zFCP /dev naming
On 04/27/2017 06:02 AM, Neale Ferguson wrote: Thanks Mark. One PITA with the new naming scheme is that it is still different from LinTel as the WWN and LUN components are prefixed by 0x on s390x but not so on LinTel. I would be very interested in some example output of "ls -laF /dev/disk/by-path/" of both x86 and s390x. Currently, I cannot imagine how the "new" (for zfcp) naming scheme could be any different on architectures, because zfcp now makes use of the very same common code creating the strings for WWPN and LUN which has always been there for x86 et al. See also below for common code by-path formatting of LUNs <256 which is indeed decimal rather than hex (on any architecture). On 4/26/17, 11:06 PM, "Linux on 390 Port on behalf of Mark Post" wrote: On 4/26/2017 at 09:43 PM, Neale Ferguson wrote: What level of s390-utils changed the zFCP device naming from: ccw--zfcp-: or ccw--zfcp-:-part to /dev/disk/by-path/ccw--fc--lun--part We had a bug reported against this for SLES12 SP2. It was against systemd/udev. The version we have is udev-228. SLES12 SP2 got the systemd change via upstream and s390-tools ships a compat udev rule /lib/udev/rules.d/59-zfcp-compat.rules, in order to _additionally_ create the old zfcp-specific by-path naming scheme. # lsscsi [0:0:1:635] diskIBM 2145 /dev/sda [1:0:0:1087324290] diskIBM 2107900 1400 /dev/sdc # lsscsi -x [0:0:1:0x027b_] diskIBM 2145 /dev/sda [1:0:0:0x4082] diskIBM 2107900 1400 /dev/sdc not unique because T10 SAM does not define 2nd level here # lsscsi -xx [0:0:1:0x027b] diskIBM 2145 /dev/sda [1:0:0:0x408240cf] diskIBM 2107900 1400 /dev/sdc # l /dev/disk/by-path/ total 0 lrwxrwxrwx 1 root root 9 Apr 25 19:02 ccw-0.0.50c0-fc-0x500507680b2281fb-lun-0x027b -> ../../sda lrwxrwxrwx 1 root root 9 Apr 25 19:02 ccw-0.0.50c0-zfcp-0x500507680b2281fb:0x027b -> ../../sda lrwxrwxrwx 1 root root 9 Apr 25 19:02 scsi-0:0:1:635 -> ../../sda lrwxrwxrwx 1 root root 9 Apr 27 12:06 ccw-0.0.1900-fc-0x50050763070845e3-lun-0x408240cf -> ../../sdc lrwxrwxrwx 1 root root 9 Apr 27 12:06 ccw-0.0.1900-zfcp-0x50050763070845e3:0x408240cf -> ../../sdc lrwxrwxrwx 1 root root 9 Apr 27 12:06 scsi-0:0:0:1087324290 -> ../../sdc Ubuntu 16.04 got the systemd change via upstream but does not ship a compat rules because as the first release on s390x there is no regression. # lsscsi [0:0:0:1087389826]diskIBM 2107900 1400 /dev/sda [2:0:1:607] diskIBM 2145 /dev/sdj # lsscsi -x [0:0:0:0x4082] diskIBM 2107900 1400 /dev/sda not unique because T10 SAM does not define 2nd level here [2:0:1:0x025f_] diskIBM 2145 /dev/sdj # lsscsi -xx [0:0:0:0x408240d0] diskIBM 2107900 1400 /dev/sda [2:0:1:0x025f] diskIBM 2145 /dev/sdj # l /dev/disk/by-path/ lrwxrwxrwx 1 root root 9 Apr 25 16:15 ccw-0.0.1900-fc-0x50050763070845e3-lun-0x408240d0 -> ../../sda lrwxrwxrwx 1 root root 9 Apr 27 12:12 ccw-0.0.50c0-fc-0x500507680b2281fb-lun-0x025f -> ../../sdj (I assume it is a udev rule that does this - if so which one?) I can't find any specific rule that does this. I suspect the code that did this is in src/udev/udev-builtin-path_id.c Yes, upstream commit: https://github.com/systemd/systemd/commit/e7eb5a8d88367a755944fdda3023a308e5272953. Also, does the FCP standard define the size of lun? It's T10 SAM, the SCSI Architecture Model, which defines size (64 bit) and formats of LUN. [http://www.t10.org/drafts.htm#SCSI3_ARCH] In the kernel header lun is u64 The Linux kernel always handles LUN as opaque u64 without trying to parse or interpret any of the different LUN formats. However, since T10 SAM defines the u64 LUN as composed of up to 4 (hierarchical) levels, the Linux kernel uses a special bijective mapping to represent the 64 bit binary LUN as a "handy" decimal "SCSI LUN" to user space. The user can see this as the fourth part in the "HCTL" name of a SCSI device consisting of ::target>: all of which are decimal numbers. This is the Linux SCSI stack midlayer naming scheme which exists for any SCSI transport includig but not limited to FCP. With FCP, the FCP device maps to a scsi host (unpredictably numbered from zero on dynamic host allocation), with zfcp, the scsi bus is always 0 (some parallel SCSI host bus adapters having >= 2 ports accessed over the same hardware device chip use this), with FCP, the target port (fc_rport) maps to a scsi target (unpredictably numbered from zero on dynamic port discovery and allocation). The LUN levels in a hex representation are 0x.
