ZFS Can I create a ZFS pool on bare device?

[poorandunlucky]

Do I need a partition table, either GPT or MBR, on a disk if I want to boot from and use a ZFS filesystem on it?

Can I just zpool create /dev/ada0 ? Then write zfsloader and zfsboot to the disk? Then boot and use it normally?

 

[SirDice]

Do I need a partition table, either GPT or MBR, on a disk if I want to boot from and use a ZFS filesystem on it?

Not if you want to boot from it.

Then write zfsloader and zfsboot to the disk?

Write it to where? There's no boot partition for them if you used the whole drive.

As long as it's for data only, not to boot from, you can use the whole disk for ZFS. But if you want to boot from the disk you're going to need a partition table and a boot partition. The BIOS/UEFI doesn't know how to read ZFS so you cannot boot from it directly.

 

[tobik@]

Previous (related?) discussion: Thread 60344

 

[poorandunlucky]

Not if you want to boot from it.

Write it to where? There's no boot partition for them if you used the whole drive.

As long as it's for data only, not to boot from, you can use the whole disk for ZFS. But if you want to boot from the disk you're going to need a partition table and a boot partition. The BIOS/UEFI doesn't know how to read ZFS so you cannot boot from it directly.

Well those things are written at specific intervals on the disk, like so many blocks in, I thought maybe ZFS, when writing its own stuff, would deliberately leave a few blocks empty in case someone wants to write boot data there... (Though I guess they'd set themselves up for possible autistic fits of rage that way, with the loss of a few KB per drive and all...)

Previous (related?) discussion: Thread 60344

I went to clean my watched threads not long after posting this and I saw that lol

Somewhat... I'm not having problems booting now, though, and I'm not in a VM...

I could almost boot then, and I was having the same problem this time when I was trying to boot from an OS that had its various parts on different datasets... Like I had a dataset for /etc, another for /boot, another for /usr, etc...

I eventually gave-up and let the auto-installer do its thing...

I was just wondering if ZFS more or less worked like flash memory, where you had set intervals at the beginning for boot data... guess not...

 

[SirDice]

Well those things are written at specific intervals on the disk, like so many blocks in, I thought maybe ZFS, when writing its own stuff, would deliberately leave a few blocks empty in case someone wants to write boot data there

The traditional BIOS boot uses a bootsector. There's a little less than half a KB of space available. Nowhere near enough to add code that's capable of reading ZFS. With FreeBSD the MBR has just enough code to figure out where the freebsd-boot partition is and load that code into memory. UEFI boot allows for more space but that requires a EFI partition to boot from. So you're basically always stuck with a partition, either freebsd-boot or an EFI partition.

 

[usdmatt]

I have done this on one system as for some reason it just wouldn't boot off ZFS when I set it up as normal with GPT partitions. I can't remember exactly what I did and I wouldn't recommend it unless it's necessary. I probably found it here - https://forums.freebsd.org/threads/50525/, and it is mentioned in the zfsboot() man page.

I also don't know whether the feature support of this is in sync with the main kernel. I haven't dared upgrade my boot pool to find out.

zfsboot is used on BIOS-based computers to boot from a filesystem in a
ZFS pool. zfsboot is installed in two parts on a disk or a partition
used by a ZFS pool. The first part, a single-sector starter boot block,
is installed at the beginning of the disk or partition. The second part,
a main boot block, is installed at a special offset within the disk or
partition. Both areas are reserved by the ZFS on-disk specification for
boot use. If zfsboot is installed in a partition, then that partition
should be made bootable using appropriate configuration and boot blocks
described in boot(8).

 

[poorandunlucky]

usdmatt: I think my problem was that I had /etc in a dataset on its own... /boot was in a dataset, /etc was in a dataset, /var, and I think I even put the other folders in their own datasets just because why not, and the "why not" is that when booting, ZFS only mounts the boot dataset, in my case, it was mounting /boot, but it was missing /etc, /bin, /sbin, /lib, etc... ZFS doesn't recursively mount datasets before loading the kernel...

I'm not sure of any of this, though... I'm not a computer scientist, I didn't try methodically a bunch of times or anything like that... I could remember things wrong, and I could be wrong, but if I was to re-attempt, I would try to find out what's the minimal amount of stuff that needs to be on the same dataset as /boot to actually boot from a ZFS volume that has no partition table of any kind on it, other than ZFS metadata or whatever it's called...

 

[usdmatt]

ZFS only mounts the boot dataset,

Yeah, don't put /etc on its own file system. Regardless of whether you use ZFS or not, the system only mounts the root file system during boot. Mounting of additional file systems happens quite late during boot - and is controlled by configuration/scripts stored in /etc...

Personally I just put my entire system on one dataset. Makes backing up / restoring easy and I'm not really bothered about saving a bit of space by compressing certain paths when the entire system is only ~600MB in the first place. If I'm going to be storing data on a system (mail/websites/databases/whatever), I create additional datasets for that once the system is up and running.

 

[poorandunlucky]

Yeah, don't put /etc on its own file system. Regardless of whether you use ZFS or not, the system only mounts the root file system during boot. Mounting of additional file systems happens quite late during boot - and is controlled by configuration/scripts stored in /etc...

Personally I just put my entire system on one dataset. Makes backing up / restoring easy and I'm not really bothered about saving a bit of space by compressing certain paths when the entire system is only ~600MB in the first place. If I'm going to be storing data on a system (mail/websites/databases/whatever), I create additional datasets for that once the system is up and running.

True... it's a bit autistic and a backwards way to go at it now that you mention it... I just wanted to keep checksums and copies of /etc while I wanted compression elsewhere, and nothing other places...