• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Migrating btrfs to zfs

S

seijirou

n00b
Joined
Feb 28, 2012
Messages
34
Real quick to get this out of the way. If you're not typically a contrary person scroll down to below the line. ;)

If you want to ask why? : I did a move a while ago from zfs to btrfs to gain the flexibility afforded by btrfs' balance feature that lets me add and remove drives and change raid levels which helps a lot as a home user with commodity hardware. It also supports defrag which I think is pretty important for a COW filesystem.

While the balance feature works okay usually, unfortunately in my real world btrfs is really bad at basically everything else and defrag is essentially mutually exclusive with snapshots due to the decoupling so it may as well not exist.

If you want to disagree that btrfs sucks : perhaps in your application it doesn't suck, but in my real world experience it's complete garbage. It sucks for me, and that's all that matters to me when I go to use it.

----------------------------------------
I'm currently using Rockstor (kind of like freenas for btrfs if you're not familiar) which is built on Centos7.

Here's my idea, I'm all ears for a better one. I don't have enough auxiliary storage to backup all my data, do a clean wipe, and copy it all back. So I'm thinking I may be able to install ZFS On Linux (ZOL) stand up a pool and locally migrate the data. The hopes being that I can then install either freenas or omnios+napp-it and import the pool created by ZOL. I figure I'll test this out in a VM first. Think it'll work?
 
yep i agree. stand up the pool and then do a cp -r
 
So I did some testing and I think I'm going to return to napp-it. I gave freenas a look (haven't touched it since they went to 8.x) and 9.x doesn't look too bad but something about it just didn't jive with me. I also took a look at their 10 alpha and I'm definitely not a fan of where freenas is apparently headed in that regard. Thanks Gea for keeping napp-it grounded!

Anyhow, something that came up once out of several iterations of testing was importing the pool brought it up in a degraded state because one of the drives changed labels or something. It didn't cause any file issues and was very easily recoverable but does make me wonder if I could end up with a faulted pool if it happens to enough drives.

I think the way ZOL and omnios handle uniquly identifying drives is different enough that I'm not sure there's a direct foolproof solution. But I'm thinking to be extra safe I'll see if I can boot from an omnios thumb drive and if I can successfully import the pool there, I should be able to then export it again in a way that will ensure consistency.

Sound about right?
 
Phantum said:
Why not rsync -ar or mv -r (which is atomic) instead or cp -r?
Click to expand...

If something were to happen during the copy the cp method would keep the source intact.
 
Last edited by a moderator:
seijirou said:
Anyhow, something that came up once out of several iterations of testing was importing the pool brought it up in a degraded state because one of the drives changed labels or something. It didn't cause any file issues and was very easily recoverable but does make me wonder if I could end up with a faulted pool if it happens to enough drives.
Click to expand...

The disks that are a member of a pool are stored in the pool. If you switch disks around, it can happen, that the disks are missing/not found ending in a pool degraded or offline state.
This is not a real problem as ZFS simply goes to offline when too many disks for the selected redundancy level fail and go back to degraded/online when they come back. The worst thing that can happen is that you need to export/import as this re-reads all disks and a resilver or scrub to check the raid consistency.

The problem mostly occur, when disk enumeration is based on a optionally changing bootup order or based on a physical controller port. Solaris and OmniOS on a current LSI HBA will always and only use WWN enumeration. This is like the Mac adress of a Nic unique and in the disk firmware. Even if you move such a disk to another server, it keeps the number. In such a case, a "move disks around" is possible without any problem.
 
Well for some reason omnios would hang instead of boot. I got openindiana to work though (strange because they should be the same difference I'm told).

The migration worked. I was able to get all my data on to a single 3t drive pool created with ZOL, and import it in to openindiana. From there I created new pools with drives that were previously running btrfs and copied back to my primary and backup pools without issue.

I'm running on OI Hipster for now, I'll circle back and see if I can sort out omnios but that's for another thread.
 
You must log in or register to reply here.
Back
Top