[LU-6610] lfs df -h query hangs when OST1 is unmounted/offline manually Created: 18/May/15  Updated: 05/Aug/20  Resolved: 05/Aug/20

Status: Resolved
Project: Lustre
Component/s: None
Affects Version/s: Lustre 2.7.0
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Paramita varma (Inactive) Assignee: WC Triage
Resolution: Duplicate Votes: 0
Labels: None
Environment:

Scientific Linux release 6.6 (Carbon)


Attachments: Text File OSt-on-disk-device-commandPrompt-output.txt     Text File dmesg.txt     Text File log-Messages.txt     Text File ost-on-disk-device-var-log-msg.txt    
Issue Links:
Related
is related to LU-8544 recovery-double-scale test_pairwise_f... Resolved
Severity: 3
Epic: client, hang, mount
Project: Test Infrastructure
Rank (Obsolete): 9223372036854775807

 Description   

Hi,

Test setup : 1 Single Scientific Linux VM with memory: 1 GB and
Disk space of 50 GB, this VM has all Lustre components configured in it : i.e ,
===========
1 MDS,
2 MDTs
2 OSTs
and a client.
============================================
Note : HA is not configured for the OSTs at the backend.
All the MDTs and OSTs are created on Loop devices.
=============================================

  1. lfs df -h output before I started the test :
    =====================================================
    [root@localhost lustre]# lfs df -h
    UUID bytes Used Available Use% Mounted on
    lustre-MDT0000_UUID 7.2G 435.8M 6.2G 6% /mnt/lustre[MDT:0]
    lustre-MDT0001_UUID 9.0G 536.8M 7.9G 6% /mnt/lustre[MDT:1]
    lustre-OST0000_UUID 14.9G 441.2M 13.7G 3% /mnt/lustre[OST:0]
    lustre-OST0001_UUID 14.9G 441.2M 13.7G 3% /mnt/lustre[OST:1]

filesystem summary: 29.9G 882.5M 27.5G 3% /mnt/lustre
=========================================================

  1. mount command output :
    =====================
    /dev/mapper/VolGroup-lv_root on / type ext4 (rw)
    proc on /proc type proc (rw)
    sysfs on /sys type sysfs (rw)
    devpts on /dev/pts type devpts (rw,gid=5,mode=620)
    tmpfs on /dev/shm type tmpfs (rw)
    /dev/sda1 on /boot type ext4 (rw)
    none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
    sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
    /dev/loop0 on /mnt/mds1 type lustre (rw,loop=/dev/loop0)
    /dev/loop1 on /mnt/ost1 type lustre (rw,loop=/dev/loop1)
    /dev/loop2 on /mnt/ost2 type lustre (rw,loop=/dev/loop2)
    localhost@tcp:/lustre on /mnt/lustre type lustre (rw,user_xattr,flock)
    /dev/loop7 on /mnt/mds2 type lustre (rw)
    ==================================================
  1. Below are the steps to reproduce the issue :

1.mounted Lustre filesystem on a client, executing the script
</lustre/tests/llmount.sh >
2. checked lfs df -h command output. All were fine , nicely displaying the
MDTs/OSTs.
3. Now from client manually unmount/offline the device on which OST1 is
configured.
4. Type the command lfs df -h on the client, it hangs.
5. /var/log/messages or dmesg continuously prints messages "LustreError: : lustre-OST0000_UUID: not available for connect from 0@lo (no target). If you are running an HA pair check that the target is mounted on the other server.

6. The command <lfs df -h> should come out of the loop and throw some error message at the user space printing OST is unavailable , or user/client should be not allowed to unmount OST just by typing simple unix unmount command. If it is allowed then error condition should be handled .
======================

  1. when lfs df -h was stuck :
    ========================
    [root@localhost lustre]# lfs df -h
    UUID bytes Used Available Use% Mounted on
    lustre-MDT0000_UUID 7.2G 435.8M 6.2G 6% /mnt/lustre[MDT:0]
    lustre-MDT0001_UUID 9.0G 536.8M 7.9G 6% /mnt/lustre[MDT:1]

*********************HUNG**************************************

Attaching /var/log/messages and dmesg
===================================



 Comments   
Comment by Paramita varma (Inactive) [ 25/May/15 ]

Hi,

Today I tried the scenario with Disk device as well instead of using loop device.
This time the additional OST was created on disk device but still seeing the issue.

Thanks & Regards,
Paramita Varma

Generated at Sat Feb 10 02:01:42 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.