Cannot mount ssd drive with usb adaptor

C

cduret

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

@ gpart show da0
Code: 
=>        63  1000215153  da0  MBR  (477G)
          63  1000215153    1  ntfs  (477G)

@ file -s /dev/da0s1
Code: 
/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
Code: 
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
Code: 
FUSE exfat 1.2.4
ERROR: bad cluster 0xfffffff7 while reading root directory.

What's wrong with my commands ?
 
Last edited:
cduret said:
Code: 
@ 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?
Click to expand...

Did you try
Code: 
 ntfs-3g /dev/da0 /mnt/usb
as the message suggests?
 
getopt said:
Post # gpart list da0.
Click to expand...

@ gpart list da0
Code: 
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
 
Last edited:
cduret said:
..........
Code: 
@ file -s /dev/da0s1
/dev/da0s1: DOS/MBR boot sector
..........
Click to expand...

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:
Code: 
# 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.
 
Indeed it is exfat filesystem.

@ dd if=/dev/da0s1 count=1 | od -c
Code: 
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
 
Last edited:
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:
Code: 
#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
Code: 
# dd if=/dev/da0 bs=1048576 of=/dev/null
 
I have tried a read of the disk without any error messages :

@ dd if=/dev/da0 bs=1048576 of=/dev/null
Code: 
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
Code: 
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
Code: 
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
Code: 
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
 
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 ;) )
Code: 
#
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):
Code: 
# 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]
 
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.
 
Just to wrap this one up.
cduret said:
I have successfully used it on Windows and Linux
Click to expand...
This fs was created and used outside of FreeBSD. When trying to mount on FreeBSD with mount.exfat-fuse error occurred:
cduret said:
Code: 
FUSE exfat 1.2.4
ERROR: bad cluster 0xfffffff7 while reading root directory.
Click to expand...
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.
 
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.
Click to expand...
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.
 
You must log in or register to reply here.
Back
Top