https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-6982 Lustre <p>Do not set the option to record (rw) discs when mounting. All discs<br/> mode (ro) regardless of the setting mount options.<br/> Connecting Remote Client (mount in read mode) can not only locally on a server</p> <a href="https://build.hpdd.intel.com/job/lustre-master/3133/">https://build.hpdd.intel.com/job/lustre-master/3133/</a><br/> arch=x86_64,build_type=server,distro=el7,ib_stack=inkernel/ LU-6982

Not mounted drives in recording mode

Bug Major Resolved Not a Bug WC Triage Alex Tue, 11 Aug 2015 02:50:54 +0000 Fri, 21 Jan 2022 01:24:26 +0000 Fri, 21 Jan 2022 01:24:26 +0000 1 5 <p>I'm not quite sure I understand the original bug report, but are you asking for read-only mount support like <a href="https://jira.whamcloud.com/browse/LU-5553" title="Support &quot;remount-ro&quot; option of the ldiskfs backend" class="issue-link" data-issue-key="LU-5553"><del>LU-5553</del></a>?</p> <p>It is necessary that the file system has been mounted in the mode (rw) by default, but unfortunately mounted mode only (ro). I need to work mode (rw)</p> <p>Hi Bob,<br/> Can you look into this issue?<br/> Thanks.<br/> Joe</p> <p>Bob, you had mentioned that the RHEL7 server mount was reporting read-only (ro) to the mount command, even though the mountpoint was actually mounted read-write and showed up correctly in /proc/mounts.</p> <p>Alex, are you actually seeing errors in your Lustre usage, or is this only related to how "mount" or "/proc/mounts" show the state?</p> <p>If you are actually seeing usage errors, can you please provide your actual mount commands, the output from "cat /proc/mounts", and any error messages on the console (client, MDS, OSS).</p> <p>As far as I can tell this is a non issue. strictly cosmetic. output from "cat /proc/mounts" always did show mounted mds/ost volumes as 'ro'. mount command began reporting the same thing starting in el7 because the mtab file became a symlink into /proc in el7. prior to that mtab was a real file.</p> <p>Bob, you are correct, and I've never noticed this before, but the server mounts on my 2.5 system are indeed all showing "ro" in /proc/mounts.</p> <p>I'm guessing that the problem is that we are not implementing the super_block operations method on the pseudo mount point to print the mount options, so "ro" is just the default option. It would probably be trivial to save the passed in mount options and print them out again. </p> <p>cat /proc/mounts<br/> rootfs / rootfs rw 0 0<br/> proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0<br/> sysfs /sys sysfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0<br/> devtmpfs /dev devtmpfs rw,seclabel,nosuid,size=1932528k,nr_inodes=483132,mode=755 0 0<br/> securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0<br/> tmpfs /dev/shm tmpfs rw,seclabel,nosuid,nodev 0 0<br/> devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0<br/> tmpfs /run tmpfs rw,seclabel,nosuid,nodev,mode=755 0 0<br/> tmpfs /sys/fs/cgroup tmpfs rw,seclabel,nosuid,nodev,noexec,mode=755 0 0<br/> cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd 0 0<br/> pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0<br/> cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0<br/> cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpuacct,cpu 0 0<br/> cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0<br/> cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0<br/> cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0<br/> cgroup /sys/fs/cgroup/net_cls cgroup rw,nosuid,nodev,noexec,relatime,net_cls 0 0<br/> cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0<br/> cgroup /sys/fs/cgroup/perf_event cgroup rw,nosuid,nodev,noexec,relatime,perf_event 0 0<br/> cgroup /sys/fs/cgroup/hugetlb cgroup rw,nosuid,nodev,noexec,relatime,hugetlb 0 0<br/> configfs /sys/kernel/config configfs rw,relatime 0 0<br/> /dev/vda1 / ext4 rw,seclabel,relatime,data=ordered 0 0<br/> selinuxfs /sys/fs/selinux selinuxfs rw,relatime 0 0<br/> systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=29,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0<br/> mqueue /dev/mqueue mqueue rw,seclabel,relatime 0 0<br/> debugfs /sys/kernel/debug debugfs rw,relatime 0 0<br/> hugetlbfs /dev/hugepages hugetlbfs rw,seclabel,relatime 0 0<br/> hard-mgs0/mgs0 /mnt/lustre/local/mgs0 lustre ro,seclabel 0 0<br/> hard-ost0/ost0 /mnt/lustre/local/ost0 lustre ro,seclabel 0 0<br/> hard-mdt0/mdt0 /mnt/lustre/local/mdt0 lustre ro,seclabel 0 0</p> <p>Mounted with parameters on the server<br/> hard-mgs0/mgs0 /mnt/lustre/local/mgs0 lustre defaults,_netdev,acl,user_xattr, 0 0<br/> hard-mdt0/mdt0 /mnt/lustre/local/mdt0 lustre defaults,_netdev,acl,user_xattr, 0 0<br/> hard-ost0/ost0 /mnt/lustre/local/ost0 lustre defaults,_netdev,user_xattr 0 0</p> <p>Mounted with parameters on the client v2.6.94<br/> 10.5.1.1@tcp:/FS /mnt/lustre lustre rw,_netdev,flock 0 0<br/> The client is not mounted giving error<br/> kernel: <span class="error">&#91;98288.816237&#93;</span> Lustre: 2413:0:(client.c:1939:ptlrpc_expire_one_request()) @@@ Request sent has timed out for slow reply: <span class="error">&#91;sent 1439552010/real 1439552010&#93;</span> req@ffff8800107f2380 x1509376670553920/t0(0) o250-&gt;MGC10.5.1.1@tcp@10.5.1.1@tcp:26/25 lens 400/544 e 0 to 1 dl 1439552020 ref 1 fl Rpc:XN/0/ffffffff rc 0/-1</p> <p>On the server build #3139 mounted without problems<br/> cat /etc/fstab<br/> 10.5.1.1@tcp:/FS /mnt/lustre lustre rw, _netdev, flock 0 0<br/> cat /proc/mounts<br/> 10.5.1.1@tcp:/FS on /mnt/lustre type lustre (rw, seclabel, flock)</p> <p>The server mountpoints report "ro" because those mountpoints are not directly writable. They are only used for "<tt>df</tt>" and "<tt>ioctl()</tt>" commands passed to the underlying filesystem.</p> Development Rank 1|hzxk73: Rank (Obsolete) 9223372036854775807 Severity