Other How to check for existence of a filesystem?

fraxamo

fraxamo

I recently came across a USB drive and couldn't remember what was on it. So, I tried to mount it using:
Code: 
# mount -t msdosfs /dev/da1s1 /mnt
but kept getting an error of 'Invalid argument'. The output from the following commands all seemed to point to there being something at da1s1:
Code: 
# camcontrol devlist
<Generic- SD/MMC 1.00>             at scbus0 target 0 lun 0 (da0,pass0)
<Verbatim STORE N GO 2.00>         at scbus1 target 0 lun 0 (da1,pass1)
Code: 
# gpart show da1
=>      63  30924737  da1  MBR  (15G)
        63         1       - free -  (512B)
        64  30924736    1  fat32  [active]  (15G)
Code: 
# fstyp /dev/da1s1
msdosfs
Code: 
# ls -al /dev/da1*
crw-rw----  1 root  operator  0x195  1 Jan 14:06 /dev/da1
crw-rw----  1 root  operator  0x19a  1 Jan 14:07 /dev/da1s1
Code: 
# fsck_msdosfs -y /dev/da1s1
** /dev/da1s1
** Phase 1 - Read FAT and checking connectivity
** Phase 2 - Checking Directories
** Phase 3 - Checking for Lost Files
4 files, 15 GiB free (1930744 clusters)
It took a while to work out that I hadn't actually created a filesystem on the drive. Creating a new filesystem at da1s1 using the following command worked and eventually allowed me to mount the drive successfully:
Code: 
# newfs_msdos -L FILES -F 32 /dev/da1s1
This was definitely a PEBKAC error and took a lot longer to resolve than I like to admit. For future reference I'd like to script something to check for this situation. So, my question is... what is the canonical way in FreeBSD to check whether a filesystem actually exists when trying to mount a drive. Or alternatively, what output from above should have given me a clue that a filesystem didn't exist on the drive yet. Thanks
 
what does dmesg say? usually filesystem errors are logged there. Other thoughts are that fstyp might have misidentified a FATX as an msdos partition, but that's a guess.

we also would have used file -s /dev/da1*
 
It is a bit sad that fstyp, fsck_msdosfs and the mount don't agree with each other. That is hard to avoid, and points to the real-world shortcoming in the definition of the on-disk format of the ancient FAT or MSDOS file systems. It is also a little sad that mount_msdosfs doesn't give a clearer error message than "Invalid argument", but that is unfixable, because of the way errors get squeezed through a single integer errno. It would be nice if the mount command could give cleartext error messages that are human-understandable, but that's not the world we live in. As someone already said: better info might be in dmesg.

You ask about a canonical way. I don't know of any that doesn't turn into a long (and usually pointless) exercise in disk format analysis. Certainly you should start with reading the partition table, but remember that (a) some disks are not even partitioned (bad idea, but exists in the real world), and (b) the partition table doesn't have to be correct, it is only a hint. The next step has to be just trying to mount (preferably in read-only mount) all suspected file systems, and see what happens. If the mount succeeds (at least sort of), some form of fsck (or scrub) should be done to make sure the file system isn't wrecked.
 
atax1a said:
what does dmesg say?
Click to expand...
This is what dmesg contained before I created the new filesystem:
Code: 
# dmesg | grep da1
da1 at umass-sim1 bus 1 scbus1 target 0 lun 0
da1: <Verbatim STORE N GO 8.07> Removable Direct Access SPC-2 SCSI device
da1: Serial Number 05175434000051
da1: 40.000MB/s transfers
da1: 14800MB (30310400 512 byte sectors)
da1: quirks=0x2<NO_6_BYTE>
da1: Delete methods: <NONE(*),ZERO>
GEOM: new disk da1
 
atax1a said:
what did it say around that?
Click to expand...
Good point. Unfortunately I didn't capture the lines above and below the grep and now they've gone. I might try and recreate the situation with another USB drive. Here's the output from /var/log/messages but it's not telling me much unless I'm missing something:
Code: 
Jan  1 14:06:20 t470 kernel: ugen0.5: <Verbatim STORE N GO> at usbus0 (disconnected)
Jan  1 14:06:20 t470 kernel: umass1: at uhub0, port 4, addr 4 (disconnected)
Jan  1 14:06:20 t470 kernel: da1 at umass-sim1 bus 1 scbus1 target 0 lun 0
Jan  1 14:06:20 t470 kernel: da1: <Verbatim STORE N GO 8.07>  s/n 05175434000051 detached
Jan  1 14:06:20 t470 kernel: pass1 at umass-sim1 bus 1 scbus1 target 0 lun 0
Jan  1 14:06:20 t470 kernel: pass1: <Verbatim STORE N GO 8.07>  s/n 05175434000051 detached
Jan  1 14:06:20 t470 kernel: (pass1:umass-sim1:1:0:0): Periph destroyed
Jan  1 14:06:20 t470 kernel: (da1:umass-sim1:1:0:0): Periph destroyed
Jan  1 14:06:20 t470 kernel: umass1: detached
Jan  1 14:06:42 t470 kernel: usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device Verbatim STORE N GO (0x18a5:0x0302
)
Jan  1 14:06:42 t470 kernel: ugen0.5: <Verbatim STORE N GO> at usbus0
Jan  1 14:06:42 t470 kernel: umass1 on uhub0
Jan  1 14:06:42 t470 kernel: umass1: <Verbatim STORE N GO, class 0/0, rev 2.00/2.00, addr 5> on usbus0
Jan  1 14:06:42 t470 kernel: umass1:  SCSI over Bulk-Only; quirks = 0x0100
Jan  1 14:06:42 t470 kernel: umass1:1:1: Attached to scbus1
Jan  1 14:06:42 t470 kernel: pass1 at umass-sim1 bus 1 scbus1 target 0 lun 0
Jan  1 14:06:42 t470 kernel: pass1: <Verbatim STORE N GO 2.00> Removable Direct Access SPC-2 SCSI device
Jan  1 14:06:42 t470 kernel: pass1: Serial Number 1313053727121278
Jan  1 14:06:42 t470 kernel: pass1: 40.000MB/s transfers
Jan  1 14:06:42 t470 kernel: da1 at umass-sim1 bus 1 scbus1 target 0 lun 0
Jan  1 14:06:42 t470 kernel: da1: <Verbatim STORE N GO 2.00> Removable Direct Access SPC-2 SCSI device
Jan  1 14:06:42 t470 kernel: da1: Serial Number 1313053727121278
Jan  1 14:06:42 t470 kernel: da1: 40.000MB/s transfers
Jan  1 14:06:42 t470 kernel: da1: 15100MB (30924800 512 byte sectors)
Jan  1 14:06:42 t470 kernel: da1: quirks=0x2<NO_6_BYTE>
Jan  1 14:06:42 t470 kernel: da1: Delete methods: <NONE(*),ZERO>
Jan  1 14:06:42 t470 kernel: GEOM: new disk da1
 
You must log in or register to reply here.
Back
Top