<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Thanks.  That was the problem.<br>
    <br>
    <div class="moz-cite-prefix">On 11/30/15 1:00 PM, Kuei-Yu Wang-Knop
      wrote:<br>
    </div>
    <blockquote
      cite="mid:201511301900.tAUJ0LSl007722@d03av05.boulder.ibm.com"
      type="cite">
      <p>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.<br>
        <br>
        This is the detail on the issue:<br>
        <br>
        Problem: one systemd commit ff502445 is in RHEL7.1/SLES12
        systemd,<br>
        now new systemd will try to check the status of the BindsTo
        device.<br>
        If the BindsTo device is inactive, systemd will fail the mount
        job<br>
        and unmount the file system. Unfortunately, the mknod device
        will<br>
        be always marked as inactive by systemd, and GPFS invokes mknod
        to<br>
        create block device under /dev, so hit the unmount issue.<br>
        <br>
        Fix: Udev/systemd reads device info from kernel sysfs, while
        device<br>
        created by mknod does not register in kernel, that is why,
        systemd<br>
        fails to read the device info and device status keeps as
        inactive.<br>
        Under new distros, a new tsctl setPseudoDisk command
        implemented,<br>
        takes the role of mknod, will register the pseudo device for
        each<br>
        GPFS file system in kernel sysfs before mounting, to make
        systemd<br>
        happy.<br>
        <br>
        <br>
        ------------------------------------<br>
        Kuei-Yu Wang-Knop <br>
        IBM Scalable I/O development<br>
        (845) 433-9333 T/L 293-9333, E-mail: <a class="moz-txt-link-abbreviated" href="mailto:kywang@us.ibm.com">kywang@us.ibm.com</a><br>
        <br>
        <br>
        <img src="cid:part1.03050609.01010307@genome.wustl.edu"
          alt="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 expe" height="16" border="0" width="16"><font
          color="#424282">Matt 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</font><br>
        <br>
        <font color="#5F5F5F" size="2">From: </font><font size="2">Matt
          Weil <a class="moz-txt-link-rfc2396E" href="mailto:mweil@genome.wustl.edu"><mweil@genome.wustl.edu></a></font><br>
        <font color="#5F5F5F" size="2">To: </font><font size="2">gpfsug
          main discussion list <a class="moz-txt-link-rfc2396E" href="mailto:gpfsug-discuss@spectrumscale.org"><gpfsug-discuss@spectrumscale.org></a></font><br>
        <font color="#5F5F5F" size="2">Date: </font><font size="2">11/30/2015
          01:42 PM</font><br>
        <font color="#5F5F5F" size="2">Subject: </font><font size="2">[gpfsug-discuss]
          rhel 7.1 systemd is un mounting gpfs file systems PMR 70339,
          122, 000</font><br>
        <font color="#5F5F5F" size="2">Sent by: </font><font size="2"><a class="moz-txt-link-abbreviated" href="mailto:gpfsug-discuss-bounces@spectrumscale.org">gpfsug-discuss-bounces@spectrumscale.org</a></font><br>
      </p>
      <hr style="color:#8091A5; " align="left" size="2"
        noshade="noshade" width="100%"><br>
      <br>
      <br>
      <tt>Hello all,<br>
        <br>
        Not sure if this is the a good place but we are experiencing a
        strange <br>
        issue.<br>
        <br>
        It appears that systemd is un-mounting the file system
        immediately after <br>
        it is mounted.<br>
        <br>
        #strace of systemd shows that the device is not there.  Systemd
        sees <br>
        that the path is failed and umounts the device.  Our only work
        around <br>
        currently is to link /usr/bin/umount to true.  Then the device
        stays <br>
        mounted.<br>
        <br>
        1     stat("/dev/aggr3", {st_mode=S_IFBLK|0644,
        st_rdev=makedev(239, <br>
        235), ...}) = 0<br>
        1     readlink("/sys/dev/block/239:235", 0x7ffdb657a750, 1024) =
        -1 <br>
        ENOENT (No such file or directory)<br>
        1     stat("/sys/dev/block/239:235", 0x7ffdb657a2c0) = -1 ENOENT
        (No <br>
        such file or directory)<br>
        1     socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK,
        0) = 19<br>
        <br>
        # It appears that the major min numbers have been changed<br>
        [root@gennsd4 system]# ls -l /sys/dev/block/|grep 239<br>
        lrwxrwxrwx 1 root root 0 Nov 19 15:04 253:239 -> <br>
        ../../devices/virtual/block/dm-239<br>
        [root@gennsd4 system]#  ls -l /dev/aggr3<br>
        brw-r--r-- 1 root root 239, 235 Nov 19 15:06 /dev/aggr3<br>
        [root@gennsd4 system]# ls /sys/dev/block/239:235<br>
        ls: cannot access /sys/dev/block/239:235: No such file or
        directory<br>
        <br>
        [root@gennsd4 system]# rpm -qa | grep gpfs<br>
        gpfs.gpl-4.1.0-7.noarch<br>
        gpfs.gskit-8.0.50-32.x86_64<br>
        gpfs.msg.en_US-4.1.0-7.noarch<br>
        gpfs.docs-4.1.0-7.noarch<br>
        gpfs.base-4.1.0-7.x86_64<br>
        gpfs.gplbin-3.10.0-229.14.1.el7.x86_64-4.1.0-7.x86_64<br>
        gpfs.ext-4.1.0-7.x86_64<br>
        [root@gennsd4 system]# rpm -qa | grep systemd<br>
        systemd-sysv-219-19.el7.x86_64<br>
        systemd-libs-219-19.el7.x86_64<br>
        systemd-219-19.el7.x86_64<br>
        systemd-python-219-19.el7.x86_64<br>
        <br>
        any help would be appreciated.<br>
        <br>
        Thanks<br>
        <br>
        Matt<br>
        <br>
        ____<br>
        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.<br>
        _______________________________________________<br>
        gpfsug-discuss mailing list<br>
        gpfsug-discuss at spectrumscale.org<br>
      </tt><tt><a moz-do-not-send="true"
          href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a></tt><tt><br>
        <br>
      </tt><br>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
<a class="moz-txt-link-freetext" href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a>
</pre>
    </blockquote>
    <br>
  
<br>

____
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.
<br>
</body>
</html>