# New 10TB drive wonkyness



## johnblue (Mar 1, 2019)

I added a 10TB drive to my media server via `sade` for the first time instead of the command line to try it out.  It went really smooth and I like the process.  After getting the disk online, I was able to move all of the OTA videos to it without issue.  That is until I rebooted the server.  It started complaining that it could not find the superblock for /dev/da0p1.

Great.

Long troubleshooting story short, I ended up edited /etc/fstab to remove da0 and was able to boot.  The wonkyness comes from when I ran `gpart show`:
	
	



```
# gpart show
=>        63  1953525105  ada0  MBR  (932G)
          63           1        - free -  (512B)
          64  1953525103     1  freebsd  [active]  (932G)
  1953525167           1        - free -  (512B)

=>         0  1953525103  ada0s1  BSD  (932G)
           0  1946157056       1  freebsd-ufs  (928G)
  1946157056     7368046       2  freebsd-swap  (3.5G)
  1953525102           1          - free -  (512B)

=>        40  1953525088  ada1  GPT  (932G)
          40        2008        - free -  (1.0M)
        2048  1953521664     1  freebsd-ufs  (932G)
  1953523712        1416        - free -  (708K)

=>         34  19532873661  da0  GPT  (9.1T)
           34            6       - free -  (3.0K)
           40  19532873654    1  freebsd-ufs  (9.1T)
  19532873694            1       - free -  (512B)

=>         34  19532873661  diskid/DISK-7PJNT2KC%20%20%20%20%20%20%20%20%20%20%20%20  GPT  (9.1T)
           34            6                                                            - free -  (3.0K)
           40  19532873654                                                         1  freebsd-ufs  (9.1T)
  19532873694            1                                                            - free -  (512B)
```

Is it suspicious that there are two entries for the same disk?

I am still googling around on this but if anyone has next steps to take I am game.

Thanks!


----------



## phoenix (Mar 1, 2019)

Every disk and filesystem has multiple aliases:

device node: /dev/da0 (for the disk) /dev/da0p1 (for the partition) /dev/da0s1 (for the slice), etc
GPT label: /dev/gpt/labelname
disk UUID: /dev/diskid/long-string-of-random-ish-characters
GPT UUID: /dev/gptid/a-different-string-of-random-ish-characters
UFS UUID: /dev/ufsid/another-random-ish-string-of-characters
UFS label: /dev/ufs/labelname
GEOM label: /dev/label/labelname
and so on
They're basically symbolic links that point at the physical device nodes.  They are all viewable and accessible *until* you mount one of them.  At that point, only the device/label you mounted is viewable and all the others are hidden.

This is one of the great things about GEOM on FreeBSD, that provides a lot of power, and a lot of opportunities to scare yourself and shoot your feet off.  

On Linux, this is similar to the whole /dev/disk/by-* hierarchy, which are just symlinks.  FreeBSD does it inside the kernel using separate device paths based on the label type.

So, it's perfectly normal to see multiple aliases/labels for a single device that's not mounted anywhere.  And it's perfectly normal to only see a single alias/label for a device that is mounted.

Personally, I disable disk IDs, GPT IDs, and UFS IDs via /boot/loader.conf.  The only labels I want to see are the ones I add to the GPT partition table via `gpart -l labelname`.  

```
kern.geom.label.disk_ident.enable="0"        # Disable the auto-generated Disk IDs  for disks
kern.geom.label.gptid.enable="0"        # Disable the auto-generated GPT UUIDs for disks
kern.geom.label.ufsid.enable="0"        # Disable the auto-generated UFS UUIDs for filesystems
```


----------



## johnblue (Mar 2, 2019)

phoenix said:


> This is one of the great things about GEOM on FreeBSD, that provides a lot of power, and a lot of opportunities to scare yourself and shoot your feet off.


lol.

Thanks for the info phoenix and the practical application!  Good stuff.  

I am still hitting a wall with getting the file system back online with this drive.  I am looking at this as a skill set learning exercise.  All that is on the drive is recorded broadcast TV video so I am not too worried about the data but it would be nice not to lose it.

`fsck` does nothing:
	
	



```
# fsck -t ufs /dev/da0p1
** /dev/da0p1
Cannot find file system superblock
```

`newfs -N` can at least read superblock data on the drive:
	
	



```
# newfs -N /dev/da0p1
/dev/da0p1: 9537536.0MB (19532873648 sectors) block size 32768, fragment size 4096
        using 15234 cylinder groups of 626.09MB, 20035 blks, 80256 inodes.
super-block backups (for fsck_ffs -b #) at:
192, 1282432, 2564672, 3846912, 5129152, 6411392, 7693632, 8975872, 10258112, 11540352, 12822592, 14104832, 15387072,
```

Am I reading this correctly that it thinks there are 20k superblocks to choose from?  If so, how can anyone figure out what superblock to choose from?

I installed testdisk and got this:
	
	



```
MS Data                     2008 19532871639 19532869632 [easystore]
  Solaris /home               2008 19532873647 19532871640 [/media]
  Solaris /home               2072 19532873711 19532871640
  Solaris /home               2120 19532873759 19532871640 [/media]
```

I like that testdisk saw the name "media" which is the only folder in the root of the drive.  Past that tidbit, it looks like I only have two choices to choose from 2008 or 2120 and I don't know what the consequences of choosing one over the other will be.

Guess I will run testdisk against a working drive to get a baseline of what normal should look like.  Any suggestions to defib this drive back into life are welcomed.

Thanks!


----------



## phoenix (Mar 4, 2019)

No, it's saying there are 15,234 "cylinder groups", with each one being 20,035 blocks in size.

There are 13+ superblocks to choose from, listed after the "super-block backups" label.  Each one lists the block number to pass to fsck_ffs(8) using the *-b* option.  For example `fsck_ffs -b 13` or `fsck_ffs -b 1282432` and so on.


----------



## johnblue (Mar 25, 2019)

To close out this thread .. 

I was not able to get the drive defibbed back to life so that data could be read.  It sure is a narrow swim lane to work inside of but just couldn't get a win.

Ended up getting a license for UFS Explorer and copying the data off without issue.


----------

