ZFS The best way to zpool export during shutdown

Be careful about exporting a pool, then trying to reimport it later if you've imported it on a different system.
 
jbpzbwhfkdeymdfbf said:
Can you elaborate what you mean?
Click to expand...
Sure. In theory "export" a ZFS pool is like a "super scrub". The intent is to make sure everything that is actually on the disk is consistent. ZFS is endianess agnostic which is why if you export from system A that is big endian you can import on system B that is little endian.
My "be careful" is mostly "if you export from system A, then import on system B make sure you export on system B before you import on system A".
You may get away with it 99% of the time, but that 1% it's going to be super critical data that is lost or messed up.

system pool/zroot stays mounted until almost the end so I think would be almost impossible.

The typical reason for export is to import on another system. To me this makes sense for say a zpool that represents user home or data, not your root pool. If your intent is to import a root pool into a new system at an altroot so you can compare, there may be other ways to accomplish that.
 
mer said:
Sure. In theory "export" a ZFS pool is like a "super scrub". The intent is to make sure everything that is actually on the disk is consistent. ZFS is endianess agnostic which is why if you export from system A that is big endian you can import on system B that is little endian.
My "be careful" is mostly "if you export from system A, then import on system B make sure you export on system B before you import on system A".
You may get away with it 99% of the time, but that 1% it's going to be super critical data that is lost or messed up.

system pool/zroot stays mounted until almost the end so I think would be almost impossible.

The typical reason for export is to import on another system. To me this makes sense for say a zpool that represents user home or data, not your root pool. If your intent is to import a root pool into a new system at an altroot so you can compare, there may be other ways to accomplish that.
Click to expand...
I am experimenting with dual boot FreeBSD x Linux to share disk space and being able to use snapshots mainly. On Linux it is force importing the zroot pool, on FreeBSD it just imports without complaining, probably force imports too.

It is a single disk M.2 ssd disk pool. So you think even though the same pool will not be used at the same time with 2 systems, it might cause problems? It doesn't share any datasets.
 
It's been a long time since I've dual booted systems, so this is all my opinion.

zroot pool on FreeBSD is going to have all kinds of freebsd executables, perhaps the /boot from the zroot that has the freebsd kernel.
Linux side you are going to need some storage for the Linux kernel, then importing the freeBSD root pool you gain what? Importing a pool that has all kinds of freeBsd executables?

I think you may want to look at exactly what you want to share between the two. User home directories? That makes sense and it's on a separate dataset from zroot. Maybe database type of datasets? Again that makes sense.
My problem is trying to share root pool doesn't make a lot of sense to me.
And yes I know that a home directory dataset on a single pool system is part of the root pool, I'm just advising caution because you don't want to import something that overlays an existing root directory structure (things like /bin, /sbin, /usr/bin and others)
 
jbpzbwhfkdeymdfbf said:
I am experimenting with dual boot FreeBSD x Linux to share disk space and being able to use snapshots mainly. On Linux it is force importing the zroot pool, on FreeBSD it just imports without complaining, probably force imports too.

It is a single disk M.2 ssd disk pool. So you think even though the same pool will not be used at the same time with 2 systems, it might cause problems? It doesn't share any datasets.
Click to expand...

So is your FreeBSD root inside that pool?

It sounds like a situation where I would just use `import -f`` every time. You need that for unclean shutdowns anyway.
 
mer I think you might have misunderstood what I am trying to accomplish. I will be using both systems as desktop in a shared SSD, as the first SSD drive is the fastest. It is different than partitions, because the free space is shared.
zroot/freebsd/root
zroot/freebsd/home
... other mounts
zroot/linux/root
zroot/linux/home
... other mounts

So mountpoints are none for freebsd and legacy for linux, using fstab for mounting.

It seems working without any visible problems so far.

I just wanted to hear what would be the problem with force importing without exporting in this kind of setup.
 
cracauer@ said:
So is your FreeBSD root inside that pool?

It sounds like a situation where I would just use `import -f`` every time. You need that for unclean shutdowns anyway.
Click to expand...
My setup is in the previous message. What would be the consequences of import -f every time? if any? I will not be upgrading the pool to linux one as linux has a higher version, upgrade only on FreeBSD.
 
jbpzbwhfkdeymdfbf said:
I am dual booting NixOS in the same zfs pool with FreeBSD.

What would be the best way to export the root pool during shutdown automatically?
Click to expand...
Maybe I'm overlooking something as I don't have dual boot experience, but I presume that you only need to share (ZFS based) data between OSs. *If* you assign that shared data pool to a separate data pool, couldn't you write a simple script that first exports the pool, then use zfs-unmount(8) for that pool (and verify that that has been successful) and finally issue a shutdown? I realise that in that case you'd have to "abandon" the usual shutdown command.

BTW, I'd take extra care in choosing a specific ZFS version between *one particular, carefully chosen* Linux distro versus a FreeBSD version. IIRC you cannot compare, on an one-to-one basis, a Linux ZFS versions version number with a FreeBSD ZFS versions version number (I think they are property based). Then, after your choice (I'd be biased towards choosing a ZFS based FreeBSD) has been made and you have a running setup, I'd be really conservative and pay extra care when updating the ZFS version with zpool-upgrade(8)

Edit: reading your setup and seeing your thoughts about ZFS versions. I'm looking at your setup and as far as I can see you're putting everything into one ZFS pool and that will offer a single pool based setup where you'll be able to share pool resources. However, purely based on a separation of concerns, I'd choose separate root pools for FreeBSD and Linux and a separate data pool. The booting mechanisms for a root ZFS pool are AFAIK not quite the same for Linux and FreeBSD, though I'm lacking specific knowledge in the Linux department.
 
jbpzbwhfkdeymdfbf said:
My setup is in the previous message. What would be the consequences of import -f every time? if any?
Click to expand...
I'm not a fan of using -forced options, especially when needed to be used on a regular basis as a casual method. For example, zpool-import(8):
Code: 
	     -f	     Forces import, even if the	pool appears to be potentially
		     active.

With all -forced options there is a reasoning behind using a command with or without that option. There may be circumstances that necessitate the use of -f, preferably because something might or probably have gone wrong and you're reasonably sure that forcing the issue won't get you into problems. Less preferable is that you're less reasonably sure but you don't have any other options open to you.

*If* the shutdown of an "all-integrated" pool (Linux root + FreeBSD root + ZFS data) in FreeBSD-ZFS mode has indeed been successful, then you might conclude that forced import in Linux is justified. However, how sure are you that that is the case all the time? You have two situations to account for:
  1. switch from FreeBSD usage to Linux usage
  2. switch from Linux usage to a subsequent Linux usage
In those two different cases both could have closed improperly when shutdown as usual or when running in case of another cause. That could be an OS upgrade gone wrong. Things could be aggravated by forced importing the whole pool in read-write mode, as one usually tends to do when starting an OS.

Now, these problems may eventually not occur, but you're never sure and using -f as a matter of course, obfuscates any possible problems. Also, you are jeopardizing the whole pool: when the pool is in trouble then it is very likely in trouble for both Linux and FreeBSD. When the pool is lost then it is lost for both Linux and FreeBSD, including your data*. There is no fsck(8) usage for FreeBSD ZFS and, I'm pretty sure, no such equivalent option for Linux ZFS either. That means you'll have to resort to backups.

Finally, you will be using ZFS in an unsupported manor (dual booting with one ZFS pool). I haven't seen any messages specific to this kind of dual use, though admittedly Linux ZFS is outside my FreeBSD ZFS based views. I'd like to know if OpenZFS mentions, gives advice for or against this (I haven't seen anything like that).

First thing I'd try to do is tracking down the cause for the need to use -f for a Linux boot. You might get that from your OS as a Linux distro, but more likely at OpenZFS. That may lead to a solution for not having to use -f.

If you won't be able to find a solution then, I'd reconsider using an all-in-one pool. In the end it is, of course, your choice and how much risk you want to take for both the FreeBSD OS, Linux OS and your data, but be aware of the lack of ZFS repair options as compared to a single OS set up using UFS on FreeBSD and, I imagine, also on Linux using ext4.

___
* this also holds for data integrity problems of a ZFS pool when using ZFS on only one device:
jbpzbwhfkdeymdfbf said:
[...] It is a single disk M.2 ssd disk pool.
Click to expand...
You are running ZFS without any redundancy; ZFS 101—Understanding ZFS storage and performance :
Single-device vdevs are also just what they sound like—and they're inherently dangerous. A single-device vdev cannot survive any failure—and if it's being used as a storage or SPECIAL vdev, its failure will take the entire zpool down with it. Be very, very careful here.
Click to expand...
There may be situations where one is practically forced to use ZFS without any redundancy (i.e., without using a mirror or a RaidZx setup) such as a laptop setup where only one disk drive can be installed. For any other set up I'd never choose to use ZFS without redundancy. Without redundancy, any data integrity error cannot be rectified by ZFS and losing the pool means you'll have lost all your data.
 
You must log in or register to reply here.
Back
Top