mount: already mounted or mount point busy

[Red Squirrel]

I have an esata drive dock that I use for backups and every now and then when I turn it on and go to mount the disk, I get that error. I have to go turn it off and turn it back on, try a few times, and eventually it lets me mount the disk. This has been getting worse and worse.

What would cause this to happen?

Also another thing, mdadm often segfaults when I turn a disk on or off, but it does not seem to affect the raid array.

 

[Nothinman]

What would cause this to happen?

Um, just what the error message says? Either something else already mounted the volume or something else is mounted at the target directory. Did you even look at what was mounted when you got the error?

Also another thing, mdadm often segfaults when I turn a disk on or off, but it does not seem to affect the raid array.

Also another bad sign as I've never seen mdadm segfault before...

 

[Red Squirrel]

Obviously it is not mounted or busy or I had not posted in first place. Like I said, if I turn the disk off and turn it back on, it lets me, sometimes it takes a few tries, other times it works right away.

I also noticed that when it does work, it skips sdg and goes to sdh. It's like if there is some phantom drive using sdg or something. I also sometimes get errors in dmesg that a disk sdg has failed overnight. There is actually no such disk in the system. There is sda up to sdf only.

I do have a drive in my raid that is failing as it has lot of CRC errors in the smart stats, so not sure if that can somehow cause weird issues to happen with disks in general. Waiting for the replacement drive to come in so I can replace it. Hopefully it will be in this week.

This problem started before the drive started to fail though.

 

[Nothinman]

Are you unmounting it before turning it off? And yes, there probably is a phantom drive at sdg if you're just turning it off without telling the OS you're removing it. But you shouldn't be using those device names anyway as they're volatile.

 

[Red Squirrel]

Yeah I always unmount it. The script that runs the backup job actually does it automatically and I get an email, and only turn it off when that email comes in and that I confirmed it's not mounted.

 

[silverpig]

I have a hard drive enclosure that acts kind of funny too. It's USB, but I think it does eSATA too (I'm moving so it's all in boxes on a truck right now and I can't check).

Basically, if I reboot/turn off/unmount the drive, I would have to wait about 30 minutes to turn it back on. I would have to turn the power switch off, wait a while, then turn it back on and the drive would spin back up. If I didn't do that, the drive wouldn't spin up and the OS would be confused about the state of the drive. I think it just needed to cool down or something.

It was purely a drive enclosure issue. Using the same drive in a different enclosure got rid of the problem.

 

[Red Squirrel]

After further investigation, it looks like the drive keeps trying to go into a raid array for some reason.

ata4: exception Emask 0x10 SAct 0x0 SErr 0x4050002 action 0xe frozen
ata4: irq_stat 0x00400040, connection status changed
ata4: SError: { RecovComm PHYRdyChg CommWake DevExch }
ata4: hard resetting link
ata4: link is slow to respond, please be patient (ready=0)
ata4: softreset failed (device not ready)
ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata4: link online but device misclassified, retrying
ata4: hard resetting link
ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata4.00: ATA-7: SAMSUNG HD103UJ, 1AA01110, max UDMA7
ata4.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 31/32)
ata4.00: configured for UDMA/133
ata4: EH complete
scsi 3:0:0:0: Direct-Access     ATA      SAMSUNG HD103UJ  1AA0 PQ: 0 ANSI: 5
sd 3:0:0:0: [sdg] 1953525168 512-byte hardware sectors (1000205 MB)
sd 3:0:0:0: [sdg] Write Protect is off
sd 3:0:0:0: [sdg] Mode Sense: 00 3a 00 00
sd 3:0:0:0: [sdg] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 3:0:0:0: [sdg] 1953525168 512-byte hardware sectors (1000205 MB)
sd 3:0:0:0: [sdg] Write Protect is off
sd 3:0:0:0: [sdg] Mode Sense: 00 3a 00 00
sd 3:0:0:0: [sdg] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sdg: sdg1
sd 3:0:0:0: [sdg] Attached SCSI disk
sd 3:0:0:0: Attached scsi generic sg7 type 0
md: bind<sdg>
[root@borg aov]# 
[root@borg aov]# 
[root@borg aov]# 
[root@borg aov]# cat /proc/mdstat 
Personalities : [raid6] [raid5] [raid4] 
md_d0 : inactive sdg[0](S)
      976762496 blocks
       
md0 : active raid5 sdc[0] sde[4] sdf[3] sdd[2] sdb[1]
      3907039744 blocks level 5, 64k chunk, algorithm 2 [5/5] [UUUUU]
      
unused devices: <none>

It's possible this drive was part of a raid array, what is the easiest way to clear those flags? Do I just zero out the first few MB of the drive? I'd have to reformat obviously, but it's not a big deal, just need to rerun the job.

If I stop that md_d0 raid then I can mount the drive. Though next time the drive is inserted it just creates it again.

 

[Khyron320]

Vim /etc/mdadm.conf or wherever your systdm puts it.

 

[Scarpozzi]

It sounds like whatever RAID was being used actually copied the configuration to the drive. Software/Hardware RAID typically does this in case you have a RAID adapter failure and you have to rebuild from just the disks...

Your best bet is to get the thing to mount, copy the valid data somewhere else (for safety), then remove the RAID config partition with fdisk. It's probably under 100MB, so it may not be worth reformatting over unless you just want a clean drive.



As for when you unmount, you might want to look into throwing the -l flag when you run it;

umount -l

I know this probably isn't the root issue...I've had it help when scripting because it will force a disconnect where other times you may get a "device is busy" error. (l = lazy)

 

[Red Squirrel]

Vim /etc/mdadm.conf or wherever your systdm puts it.

I just have my main array in there, but that drive was once part of that array I believe. So I think it's trying to add it as a hot spare for some reason but it fails.

 

[Nothinman]

I just have my main array in there, but that drive was once part of that array I believe. So I think it's trying to add it as a hot spare for some reason but it fails.

The old array metadata is likely still on the drive so it's attempting to reassemble the array whenever it detects the drive.

 

[Red Squirrel]

Any easy way to remove that data? Or should I just zero out the first few MB of the drive? (guessing it would be there somewhere)

 

[Crusty]

mdadm --zero-superblock /dev/device

I have no idea if that will nuke your data or not.

 

[Nothinman]

Any easy way to remove that data? Or should I just zero out the first few MB of the drive? (guessing it would be there somewhere)

Um, it's probably near the end and not the beginning since the beginning is what holds your MBR and partition table...

 

[Red Squirrel]

mdadm --zero-superblock /dev/device

I have no idea if that will nuke your data or not.

That should not affect the actual raid right, just the individual drive? Seems it's an undocumented feature.

 

[Crusty]

That should not affect the actual raid right, just the individual drive? Seems it's an undocumented feature.

Everything I saw said to give it the actual device of your disk(not /dev/md0) so it should only affect that disk.

 

[Red Squirrel]

tried it and it worked, and it does not affect the data.

It's odd that command is not in the man file or --help though. Otherwise mdadm is quite well documented compared to other apps.

 

[Nothinman]

tried it and it worked, and it does not affect the data.

It's odd that command is not in the man file or --help though. Otherwise mdadm is quite well documented compared to other apps.

It most certainly is in the man page:

--zero-superblock
              If the device contains a valid md superblock, the block is overwritten with zeros.  With --force the block where the superblock would be is overwritten even if it doesn't appear to be valid.