Re-mount A Drive Using Its Label Name

Home » CentOS » Re-mount A Drive Using Its Label Name
CentOS 8 Comments

Hello everybody,

I would like your opinion on the following question, why this happens in CentOS and how to fix this (or a possible work around).

I have a drive with no partitions and formatted with xfs filesystem. I give the drive a custom label “mydrive” and I mount it under
/dev/mountpnts/mydrive. Then, I add a corresponding entry to fstab.

These, are the steps I followed,

mkfs.xfs -L mydrive -f /dev/sdf mkdir /dev/mountpnts/mydrive mount -L mydrive /dev/mountpnts/mydrive/

cat /etc/fstab, LABEL=mydrive /dev/mountpnts/mydrive xfs noatime,nodiratime,nobarrier,logbufs=8 0 0

These steps mount the drive under the mount point specified.

If I remove the drive and insert it back in after a while, the drive doesn’t mount, even though I have the required entry in fstab.

`mount -a` doesn’t seem to work and provides me the following output,

mount: wrong fs type, bad option, bad superblock on /dev/sdj,
missing codepage or helper program, or other error
In some cases useful info is found in syslog – try
dmesg | tail or so

If I restart my server, the drive gets mounted in the correct mount point and works fine.

Can someone please shed some light on why a restart is required to re-mount a drive and if there is way to mount the drive without a restart.

Thanks,

Raghuv Adhepalli.

8 thoughts on - Re-mount A Drive Using Its Label Name

  • Raghuv Adhepalli wrote:

    Clarify, please: you *did* umount it before removing, correct?

    Was there anything significant in dmesg?

    mark

  • Also, did the drive change from sdf to sdj due to being removed/reinserted? What does parted or fdisk show about said drive?

  • do you not partition your drive first? even if you’re using the entire device? I’d expect to see this as /dev/sdf1 (or 2 or 3 or whatever). I’m not certain you -HAVE- to do such a thing.. and if I
    were a better person I’d experiment with a VM… (which I may still do, but it’s friday, I’m still at work and I’m ready to go home)

  • @Mauricio: Yes the drive’s sd name keeps changing with removal and addition. Thought labels can be used as alternative to maintain consistency. As you can see in my dmesg output, sdf changed to sdj

    @zep: No I do not use partitions. I use the entire drive.

    @mark: This is my dmesg output,

    XFS (sdf): xfs_log_force: error 5 returned. sd 0:0:9:0: [sdj] Synchronizing SCSI cache sd 0:0:9:0: [sdj] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
    mpt2sas0: removing handle(0x000e), sas_addr(0x4433221105000000)
    XFS (sdf): xfs_log_force: error 5 returned. scsi 0:0:10:0: Direct-Access ATA ST1000LM014-1EJ1 SM11 PQ: 0 ANSI:
    6
    scsi 0:0:10:0: SATA: handle(0x000e), sas_addr(0x4433221105000000), phy(5), device_name(0x0000000000000000)
    scsi 0:0:10:0: SATA: enclosure_logical_id(0x500605b007292d30), slot(5)
    scsi 0:0:10:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
    scsi 0:0:10:0: qdepth(32), tagged(1), simple(1), ordered(0), scsi_level(7), cmd_que(1)
    sd 0:0:10:0: Attached scsi generic sg5 type 0
    sd 0:0:10:0: [sdj] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
    sd 0:0:10:0: [sdj] 4096-byte physical blocks sd 0:0:10:0: [sdj] Write Protect is off sd 0:0:10:0: [sdj] Mode Sense: 7f 00 10 08
    sd 0:0:10:0: [sdj] Write cache: enabled, read cache: enabled, supports DPO
    and FUA
    sdj: unknown partition table sd 0:0:10:0: [sdj] Attached SCSI disk XFS (sdj): Filesystem has duplicate UUID
    a05866dd-f84e-4873-9c39-5e264cd929c0 – can’t mount XFS (sdf): xfs_log_force: error 5 returned.
    [root@raghuv07 ~]# dmesg | tail sd 0:0:10:0: Attached scsi generic sg5 type 0
    sd 0:0:10:0: [sdj] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
    sd 0:0:10:0: [sdj] 4096-byte physical blocks sd 0:0:10:0: [sdj] Write Protect is off sd 0:0:10:0: [sdj] Mode Sense: 7f 00 10 08
    sd 0:0:10:0: [sdj] Write cache: enabled, read cache: enabled, supports DPO
    and FUA
    sdj: unknown partition table sd 0:0:10:0: [sdj] Attached SCSI disk XFS (sdj): Filesystem has duplicate UUID
    a05866dd-f84e-4873-9c39-5e264cd929c0 – can’t mount XFS (sdf): xfs_log_force: error 5 returned.

  • Raghuv Adhepalli wrote:


    This concerns me. As I asked, you *did* umount the drive before removing it? I would expect that to remove the UUID from /dev/disk/by-uuid; for some reason, it’s clearly still there, and I think that’s what’s confusing the system.

    mark

  • @mark: I didn’t umount the drive before removing. Was performing hard removal. I will try clearing the concerned UUID and see if that mounts the drive back.

    Raghuv.

  • “Hard” removal? What the heck is that!? ***ALWAYS*** umount a drive before removing it. Clearly you are experiencing the side effect of and are a good example for the bad things that can happen when one does not umount a drive before removing.