New 10TB drive wonkyness

[johnblue]

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]

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]

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]

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]

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.