[gpfsug-discuss] rhel 7.1 systemd is un mounting gpfs file systems PMR 70339, 122, 000

Matt Weil mweil at genome.wustl.edu
Mon Nov 30 22:13:16 GMT 2015


Thanks.  That was the problem.

On 11/30/15 1:00 PM, Kuei-Yu Wang-Knop wrote:
>
> It is appears to be a known problem that is fixed in GPFS 4.1.1.0, 
> where RHEL 7.1 has been tested with.
>
> This is the detail on the issue:
>
> Problem: one systemd commit ff502445 is in RHEL7.1/SLES12 systemd,
> now new systemd will try to check the status of the BindsTo device.
> If the BindsTo device is inactive, systemd will fail the mount job
> and unmount the file system. Unfortunately, the mknod device will
> be always marked as inactive by systemd, and GPFS invokes mknod to
> create block device under /dev, so hit the unmount issue.
>
> Fix: Udev/systemd reads device info from kernel sysfs, while device
> created by mknod does not register in kernel, that is why, systemd
> fails to read the device info and device status keeps as inactive.
> Under new distros, a new tsctl setPseudoDisk command implemented,
> takes the role of mknod, will register the pseudo device for each
> GPFS file system in kernel sysfs before mounting, to make systemd
> happy.
>
>
> ------------------------------------
> Kuei-Yu Wang-Knop
> IBM Scalable I/O development
> (845) 433-9333 T/L 293-9333, E-mail: kywang at us.ibm.com
>
>
> Inactive hide details for Matt Weil ---11/30/2015 01:42:08 PM---Hello 
> all, Not sure if this is the a good place but we are expeMatt Weil 
> ---11/30/2015 01:42:08 PM---Hello all, Not sure if this is the a good 
> place but we are experiencing a strange
>
> From: Matt Weil <mweil at genome.wustl.edu>
> To: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>
> Date: 11/30/2015 01:42 PM
> Subject: [gpfsug-discuss] rhel 7.1 systemd is un mounting gpfs file 
> systems PMR 70339, 122, 000
> Sent by: gpfsug-discuss-bounces at spectrumscale.org
>
> ------------------------------------------------------------------------
>
>
>
> Hello all,
>
> Not sure if this is the a good place but we are experiencing a strange
> issue.
>
> It appears that systemd is un-mounting the file system immediately after
> it is mounted.
>
> #strace of systemd shows that the device is not there.  Systemd sees
> that the path is failed and umounts the device.  Our only work around
> currently is to link /usr/bin/umount to true.  Then the device stays
> mounted.
>
> 1     stat("/dev/aggr3", {st_mode=S_IFBLK|0644, st_rdev=makedev(239,
> 235), ...}) = 0
> 1     readlink("/sys/dev/block/239:235", 0x7ffdb657a750, 1024) = -1
> ENOENT (No such file or directory)
> 1     stat("/sys/dev/block/239:235", 0x7ffdb657a2c0) = -1 ENOENT (No
> such file or directory)
> 1     socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 19
>
> # It appears that the major min numbers have been changed
> [root at gennsd4 system]# ls -l /sys/dev/block/|grep 239
> lrwxrwxrwx 1 root root 0 Nov 19 15:04 253:239 ->
> ../../devices/virtual/block/dm-239
> [root at gennsd4 system]#  ls -l /dev/aggr3
> brw-r--r-- 1 root root 239, 235 Nov 19 15:06 /dev/aggr3
> [root at gennsd4 system]# ls /sys/dev/block/239:235
> ls: cannot access /sys/dev/block/239:235: No such file or directory
>
> [root at gennsd4 system]# rpm -qa | grep gpfs
> gpfs.gpl-4.1.0-7.noarch
> gpfs.gskit-8.0.50-32.x86_64
> gpfs.msg.en_US-4.1.0-7.noarch
> gpfs.docs-4.1.0-7.noarch
> gpfs.base-4.1.0-7.x86_64
> gpfs.gplbin-3.10.0-229.14.1.el7.x86_64-4.1.0-7.x86_64
> gpfs.ext-4.1.0-7.x86_64
> [root at gennsd4 system]# rpm -qa | grep systemd
> systemd-sysv-219-19.el7.x86_64
> systemd-libs-219-19.el7.x86_64
> systemd-219-19.el7.x86_64
> systemd-python-219-19.el7.x86_64
>
> any help would be appreciated.
>
> Thanks
>
> Matt
>
> ____
> This email message is a private communication. The information 
> transmitted, including attachments, is intended only for the person or 
> entity to which it is addressed and may contain confidential, 
> privileged, and/or proprietary material. Any review, duplication, 
> retransmission, distribution, or other use of, or taking of any action 
> in reliance upon, this information by persons or entities other than 
> the intended recipient is unauthorized by the sender and is 
> prohibited. If you have received this message in error, please contact 
> the sender immediately by return email and delete the original message 
> from all computer systems. Thank you.
> _______________________________________________
> gpfsug-discuss mailing list
> gpfsug-discuss at spectrumscale.org
> http://gpfsug.org/mailman/listinfo/gpfsug-discuss
>
>
>
>
>
> _______________________________________________
> gpfsug-discuss mailing list
> gpfsug-discuss at spectrumscale.org
> http://gpfsug.org/mailman/listinfo/gpfsug-discuss



____
This email message is a private communication. The information transmitted, including attachments, is intended only for the person or entity to which it is addressed and may contain confidential, privileged, and/or proprietary material. Any review, duplication, retransmission, distribution, or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is unauthorized by the sender and is prohibited. If you have received this message in error, please contact the sender immediately by return email and delete the original message from all computer systems. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20151130/18c2c083/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20151130/18c2c083/attachment-0002.gif>


More information about the gpfsug-discuss mailing list