ZFS Move a ZFS partition to whole drive?

I just wanted to test out PC-BSD so I installed it to a partition on one of my USB backup drives.
The root filesystem is ZFS in a single partition. I left the drive MBR because the first partition is Linux.

I would like to experiment and learn more about ZFS using PC-BSD's GUI tool for ZFS management, but it only works with ZFS pools where whole drives are used, not partitions. All of the /dev/adaN checkboxes are greyed out in the GUI to add storage.

If there a way I can delete the other (linux) partition and expand the ZFS partition to take up the whole drive?

Or can I copy the ZFS root partition into a new drive? Then reinstall GRUB?
 
If you can expand the ZFS partition on the current disk, ie if there is contiguous space available, then you should be able to just grow the current ZFS pool. Can you post your current partition table and ZFS config?
 
Yes, it is possible to do this, though it may involve booting from a live cd and using a partition editing package, such as pmagic? As generally its needing to get contiguous new space onto the end of the existing ZFS partition.

I know the general practice has been partitions for root pools and whole disks for non-root pools. And, since GRUB is mentioned...sounds like the first is the case. Need to have partitioning to have a place from GRUB to reside on the disk, I've never done GRUB for booting FreeBSD/ZFS so not sure what its exact requirements are.

I also recall that in the early days with Solaris, disk cache was disabled if ZFS was done on partitions. But, later the issue was resolved.

Not familiar with PC-BSD either, or this GUI tool. My only GUI type ZFS management has been with the Oracle 7420 ZFS Appliance, and even then for some of the heavier ZFS operations, I've gone rogue and go directly into 'shell'. (such as to delete a whole bunch of stale snapshots, some were over a year old, recovering more than 25TB of lost storage.) But, if it only deals with whole disks, sounds like by design its not for root pool manipulation.

OTOH, it also sounds like you have root pool on drive that is not the boot drive. Which is something I know GRUB can do, but mainly as alternative to figuring out the right key to hit at the right moment to get BIOS to boot from CD instead.

That said, I have a FreeBSD workstation at work, that I had originally setup with 4 drives for two mirrored sets. Two new 1TB drives and two 500GB pulls. The pulls came from an old failed disk array, and the remaining 'good' drives were likely to fail soon, but it seemed we could get some use before they get ground into dust before they could leave. And, they did last longer than the new 1TB drives (with only 1 year warranties), which I went through a number of DOAs or early failure before convincing boss to give me a pair of different model 2TB drives (with 3 year warranties, they both failed within 3 months of each other shortly after the warranty expired. At least I was able to get replacements in time, unlike at home where I didn't... )

So, back to situation, I had original had 3 partitions....gmirror(8) for swap and root partitions and a ZFS data pool for sysutils/backuppc, and when I moved to just a pair of 2TB drives. I combined all three, where shortly after that I converted the root partition to ZFS. Seemed like a good idea to keep backup data separated.

Well, turns out two zpools on the same disks is very poor idea, made worse because ZFS schedules I/O thinking it has the whole disk. So, I went through a process of detach mirrors, gpart(8) edit partitions, zfs send/receives, to eventually have a single zpool for most of the drive. I still kept the swap partition, though I have since un-mirrored to have more swap space, due to demands from using ports-mgmt/poudreire.

I had tried to do the whole thing minimal downtime/interruption, but ended up needing to boot from thumb drive. Next time I might remember to do things differently. Like break the mirror into a single drive rather than a degraded mirror. It wouldn't expand as the latter. Plus at some point I had switched the drives, so drive 0 is labeled disk 1 and vice-versa...

The Dreamer
 
I decided to just back up the Linux partition to external USB drive and reinstall PC-BSD to the whole drive. So far, so good: I have set up a PC-BDS ZFS root with 2 whole drives mirrored using the graphical installer. I then copied all my my Linux home data back onto the ZFS filesystem. (My laptop has 3 drives: 1 SATA (Clover dual booting hackintosh and Ubuntu), 1 MSATA, and a SATA drive caddy where the DVD-ROM used to be. The ZFS mirror pool is on the latter 2 drives.

I might be confused, but I think the PC-BSD manual says that the mirrored drives are both bootable? That would be very cool to have an automated bootable backup. Certainly much better than retarded "recovery partitions" of Windows and OS X.

I want to be able to access my home folder files in the ZFS when I boot Linux. (Until Haswell graphics gets done on FreeBSD, I might be using Linux a lot.) Anyway, it seems to work ok, but for a few minor hassles. Is there a way to just mount tank/usr/home/myhomedir when importing from Linux?

To avoid changing any ZFS attributes, I changed my Linux user UID to 1001 to match PC-BSD so I would not have to turn on sharing. I mean, I don't want to set any changes to the ZFS filesystem that might mess it up for FreeBSD.

Right now, I'm doing things a kind of dumb way:
Code:
modprobe zfs

#import all mount points
zpool import -f tank

#umount stuff I'm not going to use in Linux
zfs umount tank/var/mail
zfs umount tank/var/audit
zfs umount tank/usr/jails
zfs umount tank/usr/ports
zfs umount tank/usr/obj

I guess it doesn't hurt to leave the other mounts, but it clutters up df a bit.
 
From zpool(8) regarding the zpool import options:
Code:
         -N      Import the pool without mounting any file systems.
From there it sounds like you can selectively zfs mount tank/usr/home/myhomedir.
 
I might be confused, but I think the PC-BSD manual says that the mirrored drives are both bootable? That would be very cool to have an automated bootable backup. Certainly much better than retarded "recovery partitions" of Windows and OS X.

Yes, it is common practice with mirrored system disks to make the both bootable. That way regardless of which one fails, you'll still be able to boot from the surviving disk. Usually you can list the drives in order in BIOS to boot in such situations. While other computers you might require BIOS change or interaction. At some point in one of my (work) computers I had to move the disk to boot on its own, and have ended up with /dev/ada0 has partitions ending with '1' and /dev/ada1 has partitions ending with '0'.... Wonder which way they'll be after I get it working again.

While the computer is down, I wanted to make sure I had current backup somewhere (especially since I haven't been able to get crashplanpro to work on it, as the days of sneaking our desktops into NetBackup has ended...as we're backing up more than our license permits. Plus its management has changed groups, so I'm no longer the backup backup administrator...) I took one of the drives home to import into my home system. Since in both places the root pool is named 'zroot', I had to import it by its id with:

Code:
zpool import -o readonly=on -f -R /mew <zpool_id> mewroot

'mew' being the name of my computer at work. AFAIK, they haven't named the satanic kitten in Sluggy Freelance, so went with 'mew'. to keep with how I've been naming computers in my cubicle and that it was the character that we were fond of around when I first set up the computer. ;) Though its been a while since I kept up on the comic (also need to catch up on Dilbert...)

The Dreamer.
 
Last edited by a moderator:
Back
Top