# Cannot mount ssd drive with usb adaptor



## cduret (Dec 29, 2016)

I have successfully used it on Windows and Linux but with my FreeBSD 11 setup I have failed to use it.

`@ gpart show da0`

```
=>        63  1000215153  da0  MBR  (477G)
          63  1000215153    1  ntfs  (477G)
```

`@ file -s /dev/da0s1`

```
/dev/da0s1: DOS/MBR boot sector
```

I have used it on Linux with exfat filesystem and it worked great.
But when I wonder why on FreeBSD gpart shows ntfs ?

I have tried to mount it with sysutils/fusefs-ntfs and got error :

`@ ntfs-3g /dev/da0s1 /mnt/usb`

```
NTFS signature is missing.
Failed to mount '/dev/da0s1': Invalid argument
The device '/dev/da0s1' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?
```

I have tried to mount it with sysutils/fusefs-exfat but got also an error :

`@ mount.exfat-fuse /dev/da0s1 /mnt/usb`

```
FUSE exfat 1.2.4
ERROR: bad cluster 0xfffffff7 while reading root directory.
```

What's wrong with my commands ?


----------



## roddierod (Dec 29, 2016)

cduret said:


> ```
> @ ntfs-3g /dev/da0s1 /mnt/usb
> NTFS signature is missing.
> Failed to mount '/dev/da0s1': Invalid argument
> ...



Did you try 
	
	



```
ntfs-3g /dev/da0 /mnt/usb
```
 as the message suggests?


----------



## cduret (Dec 29, 2016)

roddierod said:


> Did you try
> 
> 
> 
> ...


same error


----------



## cduret (Dec 29, 2016)

getopt said:


> Post `# gpart list da0`.



`@ gpart list da0`

```
Geom name: da0
modified: false
state: OK
fwheads: 255
fwsectors: 63
last: 1000215215
first: 63
entries: 4
scheme: MBR
Providers:
1. Name: da0s1
   Mediasize: 512110158336 (477G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 32256
   Mode: r0w0e0
   rawtype: 7
   length: 512110158336
   offset: 32256
   type: ntfs
   index: 1
   end: 1000215215
   start: 63
Consumers:
1. Name: da0
   Mediasize: 512110190592 (477G)
   Sectorsize: 512
   Mode: r0w0e0
```


----------



## aribi (Dec 30, 2016)

cduret said:


> ..........
> 
> ```
> @ file -s /dev/da0s1
> ...



This seems to me an abnormal response for a ntfs mbr partition. Response should give much more info then just "DOS/MBR boot sector". Might be some windows volume thing. Perhaps you can verify this is a simple ntfs partition:

```
# dd if=/dev/da0s1 count=1 | od -c
00000000   353   R 220   N   T   F   S                  \0 002 004  \0  \0
.......
```
Key is in the four characters NTFS identifying itself as such.

BTW. This seems a strange layout for an ssd starting at block 63 (512 byte blocks that is) as cluster borders don't coincide with your flash blocks - this will double the wear on your ssd IMHO.


----------



## cduret (Dec 30, 2016)

Indeed it is exfat filesystem.

`@ dd if=/dev/da0s1 count=1 | od -c`

```
1+0 records in
1+0 records out
512 bytes transferred in 0.002293 secs (223266 bytes/sec)
0000000  353   v 220   E   X   F   A   T              \0  \0  \0  \0  \0
0000020   \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
0000100    ?  \0  \0  \0  \0  \0  \0  \0   q 022 236   ;  \0  \0  \0  \0
0000120   \0  \b  \0  \0  \0   x  \0  \0  \0 200  \0  \0 222 235   ;  \0
0000140   \a  \0  \0  \0 037 376   j   W  \0 001  \0  \0  \t  \b 001 200
0000160  026  \0  \0  \0  \0  \0  \0  \0 364 364 364 364 364 364 364 364
0000200  364 364 364 364 364 364 364 364 364 364 364 364 364 364 364 364
*
0000760  364 364 364 364 364 364 364 364 364 364 364 364 364 364   U 252
0001000
```


----------



## aribi (Dec 30, 2016)

So, mount.exfat-fuse says it it cannot read the root directory because cluster address is 0xfffffff7. In the source (/usr/ports/sysutils/fusefs-exfat/work/exfat-1.2.4/libexfat/exfatfs.h) it reads:

```
#define EXFAT_CLUSTER_BAD 0xfffffff7 /* cluster contains bad sector */
```
And the case of a bad cluster is not handled in the code that reads the root dir. This is something for the developers of fusefs-exfat to fix.
On the other hand, you seem to have a disk with bad sectors. That is not a good sign, the ssd should fix that itself. I suggest you check the disk with smartctl from smartmontools and/or try a blunt read of the disk to check for errors

```
# dd if=/dev/da0 bs=1048576 of=/dev/null
```


----------



## cduret (Jan 8, 2017)

I have tried a read of the disk without any error messages :

`@ dd if=/dev/da0 bs=1048576 of=/dev/null`

```
488386+1 records in
488386+1 records out
512110190592 bytes transferred in 14820.384490 secs (34554447 bytes/sec)
```

Then I have tried to run smartctl to see if it sees any errors.

`@ smartctl -d auto -i /dev/da0`

```
smartctl 6.5 2016-05-07 r4318 [FreeBSD 11.0-RELEASE-p1 amd64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Samsung based SSDs
Device Model:     SAMSUNG MZ7LN512HCHP-000L1
Serial Number:    S1ZKNXAH207076
LU WWN Device Id: 5 002538 d00000000
Firmware Version: EMT04L0Q
User Capacity:    512,110,190,592 bytes [512 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2, ATA8-ACS T13/1699-D revision 4c
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Sun Jan  8 02:40:38 2017 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
```

`@ smartctl -s on -o on -S on /dev/da0`

```
smartctl 6.5 2016-05-07 r4318 [FreeBSD 11.0-RELEASE-p1 amd64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF ENABLE/DISABLE COMMANDS SECTION ===
SMART Enabled.
SMART Attribute Autosave Enabled.
SMART Automatic Offline Testing Enabled every four hours.
```

`@ smartctl -H /dev/da0`

```
smartctl 6.5 2016-05-07 r4318 [FreeBSD 11.0-RELEASE-p1 amd64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
```

Cannot see any clue of bad sector here


----------



## aribi (Jan 8, 2017)

So you checked health with
`# smartctl -H /dev/da0`
This tells you what the drive thinks about itself, S.M.A.R.T. software in the drive says "I see no problems". Hardware ECC corrected reads are not considered a problem. But if they run in the billions the probability of "mis-correcting" is not be ignored.

This is an example of the output of a questionable drive (of which I have a box full  )

```
#
smartctl -H /dev/ada2
smartctl 6.5 2016-05-07 r4318 [FreeBSD 11.0-RELEASE-p2 amd64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
```
But if I check the actual values this PASSED is based on (using -a flag):

```
# smartctl -a /dev/ada2 | grep Pre-fail
  1 Raw_Read_Error_Rate     0x000f   117   099   006    Pre-fail  Always       -       132218442
  4 Start_Stop_Count        0x0033   100   100   020    Pre-fail  Always       -       170
  5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       2
  7 Seek_Error_Rate         0x000f   071   060   030    Pre-fail  Always       -       12927578453
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       6
 12 Power_Cycle_Count       0x0033   100   100   020    Pre-fail  Always       -       171
184 End-to-End_Error        0x0033   100   100   097    Pre-fail  Always       -       0
196 Reallocated_Event_Count 0x0033   100   100   036    Pre-fail  Always       -       2
```
Which tells me, there have been 2 reallocated sectors and millions of rereads and reseeks - so its "LeaveMyShop" for this disk.

BTW. look here for values that a healthy
SAMSUNG MZ7LN512HCHP-000L1 should provide - id 178,180 show reallocated flash blocks: https://www.smartmontools.org/ticket/632[/cmd]


----------



## wblock@ (Jan 8, 2017)

Rather than think of a bad block on the drive, think of a bug in the exfat driver, which is after all a reimplementation of a reverse-engineered proprietary filesystem.  I would suggest using a non-proprietary filesystem.  Which one you choose depends on which platforms need access to it.

aribi, be careful about some of the SMART numbers.  Seagate does some silly thing that gives huge numbers to some values like that, even though it does not indicate a problem.  Well, an additonal problem that isn't already indicated by the "Seagate" sticker.


----------



## aribi (Jan 8, 2017)

Just to wrap this one up.


cduret said:


> I have successfully used it on Windows and Linux


This fs was created and used outside of FreeBSD. When trying to mount on FreeBSD with `mount.exfat-fuse` error occurred:


cduret said:


> ```
> FUSE exfat 1.2.4
> ERROR: bad cluster 0xfffffff7 while reading root directory.
> ```


This means, from the source at /usr/ports/sysutils/fusefs-exfat/work/exfat-1.2.4/libexfat/exfatfs.h, this fat entry in the rootdir is marked as BADCLUSTER. `mount.exfat-fuse` thus decides it will not want to work with this fs and returns failure on reading the rootdir.
All in all `mount.exfat-fuse` that is currently in ports (1.2.4) will never mount an fs that has fat entries marked as badclusters in the rootdir.

All the talk about the physical state of the drive is actually an afterthought, and should be considered off topic, sorry about bringing that up.
Somewhere along the line either Windows, or Linux, silently added this bad cluster. The drive might just have a real problem that triggered that - good to know if there is valuable data on the drive.


----------



## leebrown66 (Jan 8, 2017)

wblock@ said:


> aribi, be careful about some of the SMART numbers.  Seagate does some silly thing that gives huge numbers to some values like that, even though it does not indicate a problem.  Well, an additonal problem that isn't already indicated by the "Seagate" sticker.


Not only Seagate .. and those numbers may mean something different with a different vendor.
Google (I cannot find the article) concluded that SMART is useless for predictive failure.  IIRC 40% of drives fail with no SMART problems exhibited.
I track the temperature and power-on-hours.


----------

