Migrate UFS drive from FreeNAS to DragonFly BSD

[afreedma]

Hello. After almost 6 years of using FreeNAS on my home server I've decided it's time to make a change. The plucky little box can only accomodate 4Gb of RAM so I stopped upgrading at version 8.3 and now I'm sizing up DragonFly BSD as an alternative. Problem is, the backup drive I set up under FreeNAS isn't mounting in the new environment.

I picked up a Seagate 8Tb Archive disk, attached it via eSATA, formatted it as UFS under FreeNAS then patiently waited about a week for it to trickle full (cost per Gb on the archive drives is amazing - write performance is... less amazing).

Now I've got DragonFly going, but try as I might I can't get the UFS volume mounted. I can see that the drive is using GPT (and a protective MBR) and is definitely UFS. Is there anything tricky about the way FreeNAS creates UFS volumes? Was there some evolution in FreeBSD that renders the two OS-cousins incompatible? It also seems odd that I can see slices but not partitions: I expected ls /dev/ad6* to give me something like /dev/ad6p1a since the drive is using GPT, but evidently not.

I'm yet to try anything invasive (as in, write to the disk) because I'm completely in the dark on what the cause is. Because of this my FreeNAS environment is still in-tact so I can use that for any testing/solutions.

Code:

% uname -a
DragonFly loki.misque.me 4.4-RELEASE DragonFly v4.4.3-RELEASE #5: Mon Apr 18 22:47:32 EDT 2016 root@www.shiningsilence.com:/usr/obj/home/justin/release/4_4/sys/X86_64_GENERIC x86_64

Some basic information about the disk:

Code:

% ls /dev/ad6*
/dev/ad6 /dev/ad6s0 /dev/ad6s1

% cat /etc/fstab
# Device Mountpoint FStype Options Dump Pass#
/dev/serno/4C530012740115112064.s1a / ufs rw 1 1
/dev/serno/4C530012740115112064.s1d /home ufs rw 2 2
/dev/serno/4C530012740115112064.s1e /tmp ufs rw 2 2
/dev/serno/4C530012740115112064.s1f /usr ufs rw 2 2
/dev/serno/4C530012740115112064.s1g /var ufs rw 2 2
/dev/serno/4C530012740115112064.s1b none swap sw 0 0
proc /proc procfs rw 0 0

/dev/ad6s1 /mnt/backup ufs ro 0 0

The mount effort in question:

Code:

% sudo mount -v /mnt/backup
mount_ufs: /dev/ad6s1 on /mnt/backup: incorrect super block

And my diagnostic efforts:

Code:

% sudo fdisk /dev/ad6
******* Working on device /dev/ad6 *******
parameters extracted from device are:
cylinders=15504021 heads=16 sectors/track=63 (1008 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=15504021 heads=16 sectors/track=63 (1008 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 238,(EFI GPT)
start 1, size 4294967295 (2097151 Meg), flag 80 (active)
beg: cyl 0/ head 0/ sector 2;
end: cyl 1023/ head 255/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>

% sudo disklabel64 -r ad6
disklabel64: bad pack magic number

% sudo disklabel64 -r ad6s0
disklabel64: bad pack magic number

% sudo disklabel64 -r ad6s1
disklabel64: bad pack magic number

% sudo camcontrol devlist
<ATA WDC WD20EARX-00P AB51> at scbus3 target 1 lun 0 (da0,sg0,pass0)
<ATA WDC WD30EFRX-68E 0A80> at scbus3 target 2 lun 0 (da1,sg1,pass1)
<ATA OCZ-AGILITY 1.4> at scbus3 target 3 lun 0 (da2,sg2,pass2)
<ATA WDC WD30EFRX-68A 0A80> at scbus3 target 4 lun 0 (da3,sg3,pass3)
<ATA WDC WD20EARS-00M AB51> at scbus3 target 5 lun 0 (da4,sg4,pass4)
<ATA WDC WD20EFRX-68E 0A82> at scbus3 target 6 lun 0 (da5,sg5,pass5)
<ATA WDC WD20EARS-00M AB51> at scbus3 target 7 lun 0 (da6,sg6,pass6)
<SanDisk Cruzer Fit 1.27> at scbus6 target 0 lun 0 (pass8,sg8,da8)

% sudo gpt show /dev/ad6
start size index contents
0 1 - PMBR
1 1 - Pri GPT header
2 32 - Pri GPT table
34 94 -
128 4194304 0 GPT part - FreeBSD Swap
4194432 15623858696 1 GPT part - FreeBSD UFS/UFS2
15628053128 7 -
15628053135 32 - Sec GPT table
15628053167 1 - Sec GPT header

% sudo file -s /dev/ad6
/dev/ad6: DOS/MBR boot sector; partition 1 : ID=0xee, active, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 4294967295 sectors

% sudo file -s /dev/ad6s1
/dev/ad6s1: Unix Fast File system [v2] (little-endian) last written at Thu Jan 1 00:00:00 1970, number of blocks 0, number of data blocks 0, pending blocks to free 0, system-wide uuid 0,

Any pointers would be hugely appreciated.

 

[jgreco]

Mod note: this essentially has nothing to do with FreeNAS, thread evicted to off-topic

 

[jgreco]

My primary comment here, not having played with DragonflyBSD for awhile, would be that you might want to tackle this from the other end. Create a filesystem on DragonflyBSD, then see if it's mountable on FreeNAS.

You've created an awkward situation here because probably no one here knows what the heck "disklabel64" is, or what sort of strategies DragonflyBSD uses for disk partitioning, or what the relevant commands should be. Further, if you intend for this to live on DragonflyBSD, you'd be better off having it be something that's genuinely compatible with DragonflyBSD, rather than trying to grovel around for "something that'll work" to get your data to appear there. This means partitioning the disk in DragonflyBSD, creating a UFS filesystem in DragonflyBSD, etc.

This is basically the same advice we give to people trying to bring other ZFS pools to FreeNAS. Technically it's possible to import foreign ZFS pools but it may not be a good idea.

Once you have a DragonflyBSD UFS filesystem, you could then bring it over to FreeNAS and we can see about getting it mounted on FreeNAS. You don't necessarily have to wipe your archive drive to do all this. Use a spare drive. Along the way we might learn enough to figure everything out.

 

[afreedma]

Ah - you're very right, sorry. The way I put it does sound pretty off topic. Thanks for your reply though, I'm keen for all the help I can get!

Probably a better way to put my question would be: My (actually still working!) FreeNAS 8.3 system has an external UFS drive which isn't recognised by DragonFly BSD (and from much Googling, similar results appear on FreeBSD and Linux as well). UFS is a funny old thing - not really a standard, but still the most likely candidate for shifting volumes between BSD variants.

If there's any way to put the thread back to storage that would be hugely appreciated - I suspect this is going to require some unusually arcane knowledge of disk layouts and UFS history. The upshot would be better interoperability between FreeNAS and other BSDs.

To add a little more context, the box has 6 2Tb disks in RAIDZ1 and I'm holding about 7Tb of data. The UFS external drive is my backup so is only needed for the transition, then I can reformat it and recreate my backup strategy. Getting 7Tb on a low power server onto an archive disk really does take about a week, so if there's a way to avoid that then it would save me a *lot* of time. Buying another archive disk for testing is possible, but wouldn't be my first preference - I definitely don't have a spare 8Tb disk to hand! :)

Again, thank you for the response. After a few days of fruitless searching it's nice to get some fresh ideas.

 

[jgreco]

No, the point was to maybe take a spare disk for now and format it on DragonflyBSD to see what it does. If I had a little more free time I'd go try it in a VM, but as it happens, not really a lot of that right now.

We're far more likely to be able to assist you with mounting a DragonflyBSD filesystem on FreeNAS, using FreeNAS commands and tools, than the other way around.

 

[DrKK]

Can I ask why in Muhammad's, Jesus's, and Buddha's name you are attempting to use DragonflyBSD, as opposed to one of several other obvious options which don't have some of the...uh....(trying not to start a jihad here with Dragonfly zealots)....disadvantages of Dragonfly? I am not attempting to shame you; I am truly intellectually curious as to why this was your selection.

 

[afreedma]

No, the point was to maybe take a spare disk for now and format it on DragonflyBSD to see what it does. If I had a little more free time I'd go try it in a VM, but as it happens, not really a lot of that right now.

We're far more likely to be able to assist you with mounting a DragonflyBSD filesystem on FreeNAS, using FreeNAS commands and tools, than the other way around.

Good thought - will try. Thank you.

 

[afreedma]

Can I ask why in Muhammad's, Jesus's, and Buddha's name you are attempting to use DragonflyBSD, as opposed to one of several other obvious options which don't have some of the...uh....(trying not to start a jihad here with Dragonfly zealots)....disadvantages of Dragonfly? I am not attempting to shame you; I am truly intellectually curious as to why this was your selection.

I prefer not having a web GUI (I've always found the FreeNAS interface constraining), I can't use ZFS reliably (max 4Gb of RAM on this box), I feel more comfortable on BSD systems, HAMMER looks like the best non-ZFS option open to me, DragonFly seems to be comparatively lightweight (Atom D510 CPU).

What do you see as the disadvantages of DragonFly (equally curious)?

 

[afreedma]

So I created a UFS partition on a different disk, booted FreeNAS and collected some information:

Code:

# ls /dev/ad*
/dev/ad6@    /dev/ad6p1@  /dev/ad6p2@  /dev/ada0    /dev/ada0p1  /dev/ada0p2

Sorry - I thought it was 8.3, was actually 9.2:

Code:

# uname -a
FreeBSD Loki.local 9.2-RELEASE-p15 FreeBSD 9.2-RELEASE-p15 #0 r262572+5b7d179: Mon Nov 17 16:27:51 PST 2014     root@build3.ixsystems.com:/tank/home/jkh/build/921/FN/os-base/amd64/fusion/jkh/921/FN/FreeBSD/src/sys/FREENAS.amd64  amd64

Code:

# mount -v /dev/ada0p1 /mnt/tmp
mount: /dev/ada0p1: Input/output error
/dev/md1 on /mnt (ufs, local, writes: sync 12 async 15, reads: sync 8 async 0, fsid 8fe27c5732083f50)

Code:

# fdisk /dev/ada0p1
******* Working on device /dev/ada0p1 *******
parameters extracted from in-core disklabel are:
cylinders=0 heads=16 sectors/track=63 (1008 blks/cyl)

parameters to be used for BIOS calculations are:
cylinders=0 heads=16 sectors/track=63 (1008 blks/cyl)

fdisk: invalid fdisk partition table found
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 63, size 4294967233 (2097151 Meg), flag 80 (active)
    beg: cyl 0/ head 1/ sector 1;
    end: cyl 16/ head 4/ sector 4
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>

Code:

# bsdlabel /dev/ada0
bsdlabel: disks with more than 2^32-1 sectors are not supported
# bsdlabel /dev/ada0p1
bsdlabel: couldn't read 8192 bytes from /dev/ada0p1
# bsdlabel /dev/ada0p2
bsdlabel: disks with more than 2^32-1 sectors are not supported

# camcontrol devlist
<WDC WD40EFRX-68WT0N0 80.00A80>    at scbus1 target 0 lun 0 (ada0,pass0)
<ATA WDC WD20EARX-00P AB51>        at scbus3 target 1 lun 0 (da0,pass1)
<ATA WDC WD30EFRX-68E 0A80>        at scbus3 target 2 lun 0 (da1,pass2)
<ATA OCZ-AGILITY 1.4>              at scbus3 target 3 lun 0 (da2,pass3)
<ATA WDC WD30EFRX-68A 0A80>        at scbus3 target 4 lun 0 (da3,pass4)
<ATA WDC WD20EARS-00M AB51>        at scbus3 target 5 lun 0 (da4,pass5)
<ATA WDC WD20EFRX-68E 0A82>        at scbus3 target 6 lun 0 (da5,pass6)
<ATA WDC WD20EARS-00M AB51>        at scbus3 target 7 lun 0 (da6,pass7)
<hp v220w 1100>                    at scbus7 target 0 lun 0 (pass8,da7)

# gpart show /dev/ada0
=>        34  7814037101  ada0  GPT  (3.7T)
          34           1     1  !3d48ce54-1d16-11dc-8696-01301bb8a9f5  (512B)
          35  7814037100     2  !3d48ce54-1d16-11dc-8696-01301bb8a9f5  (3.7T)

# file -s /dev/ada0
/dev/ada0: x86 boot sector; partition 1: ID=0xee, starthead 0, startsector 1, 4294967295 sectors, extended partition table (last)\011, code offset 0x0

Any tips on where to head now?

 

[DrKK]

What do you see as the disadvantages of DragonFly (equally curious)?

There are reasons DragonflyBSD has (literally now, this is not hyperbole) 0% of the server market, and 0% of the desktop market. Matt Dillon (the force behind DragonflyBSD) is a genius from the old Amiga days, but he is essentially a one man show. DragonflyBSD and HAMMER do not have a minimal quorum of developers to give an actual ecosystem activation energy, so progress is in fits and starts---in fact, HAMMER2 is now, what, 4 years? overdue, and not usable, to my knowledge. In short, it would appear to be a solution in need of a problem, that in any case lacks ecosystem ignition energy.

Those that use DragonflyBSD (all eight of them) tend to have quite a zealous view of it, and tend to lose no opportunity whatsoever to pop up on twitter, reddit, ars, and whatever fora are necessary to proselytize the greatness of DragonflyBSD.

I myself have no opinion of it, other than to say I have never found it compelling as a solution to any problem I've ever seen anyone have, and that I find its extremely extremely small market share to be a compelling vote about its efficacy for most people. And I assume I am "most people". I've installed it a few times just for completeness of experience. In each case, I discovered what everyone else discovered after playing with it for a few dozens of minutes: Why did I install this? What problem am I now solving by using this instead of {free/open}BSD? And I never (like so many others) got past the test drive. Then I call my friends and say: "So, DragonflyBSD, I've got it installed. What am I missing here?" And they say: "You're not missing anything. The correct next step is to revert back to FreeBSD."

I am sure it's a wonderful operating system. But the world already has at least 2 (or, 2.5, if you count NetBSD) wonderful operating systems in this space that are very niche successful, and do not appear to have problems for which DragonflyBSD is the solution.

Your main argument appears to be HAMMER filesystem. There are almost no serious production deployments of HAMMER. In fact, there might be none. I certainly have heard of none whatsoever in any serious enterprise. When people put their money where their mouth is, they are not eager to use DragonflyBSD or HAMMER. Take from that what you will. Maybe everyone is stupid. Or maybe it's just not worth the hassle.

 

[jgreco]

Well, as the current maintainer of one of Dillon's previous projects, Diablo, all I can say is that I hope the code's of better quality. Diablo was full of unchecked error conditions and unhandled situations when I took it over.