# Lost mounted directory after suspend/resume



## Korger (Oct 24, 2022)

Hi Everyone,

I've mounted a USB flash drive with FAT32 filesystem:

`mount -r -t msdos /dev/da0s1 /mnt`

I can read the files well.  But after I suspend the laptop and resume, the contents of /mnt are gone.  The partition is still visible:


```
ls -l /dev/da*
crw-r-----  1 root  operator  0x2b7 Oct 23 20:39 /dev/da0
crw-r-----  1 root  operator  0x2b8 Oct 23 20:39 /dev/da0s1
```
and the filesystem seems mounted:


```
mount | grep da0
/dev/da0s1 on /mnt (msdosfs, local, read-only)
```
but /mnt is empty:

```
ls -l /mnt
total 0
```

Can anyone explain what's going on and how to fix this?  I'm using 12.3-RELEASE-p2.


----------



## smithi (Oct 25, 2022)

I learned not to suspend with mounted da* filesystems many years ago, FreeBSD 7 or so.  In those days you were lucky not to crash the system, and at least had to force (-f) umount the filesystem.

No crash here now on 12.3-RELEASE-p6, but still the supposedly mounted filesystem appears empty after resuming.

At least I could now umount and re-mount the filesystem without apparent damage, though I wasn't writing or logging to it on suspend.

/etc/rc.suspend contains `sleep 3; sync;sync;sync` which reduces risk of interrupting incomplete writes, but it's a bit disappointing that this is still an issue .. not that it's an easy problem I'm sure, since daN numbers are assigned in order of arrival, not assigned to particular connectors.

This is one of the reasons I don't suspend on lid close.

Looks like "don't do that" is still the only useful advice


----------



## Korger (Oct 27, 2022)

Thanks, that's exactly what I'm experiencing on my system.  But I'm getting curious: how come mounted ada* works well after suspend/resume, but da* not?  What gives the difference?


----------



## ralphbsz (Oct 27, 2022)

The difference might be that one is a USB device, and after suspend/resume the USB subsystem doesn't come back to life correctly. 

The ada(4) driver is for disks that speak ATA (=IDE =SATA) protocol; the da(4) driver is for disks that speak SCSI protocol. That's for the block-level command set, not for the lower transport level. It turns out that USB mass storage devices speak a variant of SCSI, so they are handled under the da driver. The USB layer is below the SCSI/ATA layer in the stack.


----------



## smithi (Oct 27, 2022)

ada are (usually) fixed scsi disk (SATA) devices, on an ahci(4) controller.

da are (usually) transient scsi disk devices on umass(4) mass storage devices on USB ports.

Apart from reading the man pages, browse /var/log/messages searching 'da0|da1|ada0' through a boot, plugging and unplugging two USB sticks - no need to mount them.

You'll see first in, first served behaviour on daN.  Suspend then resume with 2 sticks in. You may or may not get them back in the same order, i.e. da1 may now be assigned to the stick previously da0.

HTH


----------

