On 5/13/20 8:10 AM, cindy.sw...@gmail.com
> Hi Grant,
> An important point is that the rpool, boot, OS components should be
> left alone and any non-rpool, boot, OS data should go into a data
> pool and not the rpool.
I hear you. I think I understand what you're saying, and why you say
it. (I've said quite similar things about volume groups for AIX and
Linux for 15+ years.)
But, I think ZFS is starting to make it into a space where doing that is
not an option.
I.e. I have a system (glorified bastion host) that is a 1U box with 4 ×
3½" drives that I'm rebuilding. The hardware RAID-6 lost 3 drives
during the current WFH climate. I've rebuilt it with new drives as a
temporary measure. But, I'd like to rebuild it again in the near future
as a 4 way ZFS /mirror/. (I really don't want to have this problem
again.) I don't need space. I need stability and longevity. I'd like
the pool to outlast the OS that's installed on the machine.
I'd really like to build a pair of them and have each machine do a zfs
send to each other's pools. That way, even if I loose four hard drives,
I would still have the files on the other machine.
Aside: The drives are multi TB for an OS install that's (considerably)
less than 10 GB.
I could partition the drives and have bpool and an rpool on them. (I
had originally thought about a 4 way mirror for bpool and RAIDZ2 for
rpool. But decided that everything could easily fit in the 4 way
mirror.) The reason for having rpool separate was that GRUB doesn't
support booting from any form of Z-RAID more complex than mirroring.
So, I guess that I could still partition the drives and have rpool dpool
on the same drives. But that seems a little silly to me for my
particular use case.
So, I'm in a situation that really lends itself to having OS specific
files and DATA (non-OS specific) file in the same pool. The hardware
doesn't lend itself to attaching more drives. Nor do I think I would do
so if it did. I simply don't see the need. Not when each system's
rpool can hold the necessary data from the other system.
Please correct me if I'm wrong about any of this.
> I wouldn't spend too much time on the rpool components and how its
I have a nasty habit of asking that pesky "why" question, particularly
in the context of why something was done the way that it was.
> By keeping rpool and non-rpool data separate, you can apply file system
> properties to more easily match your data and rpool stays small and
> mostly static and also easier to recover.
Having rpool and dpool isn't really an option for this use case.
> Adding non-rpool data to an rpool is not supported.
I'm taking that to mean that Oracle (et al.) won't support me as in hold
my hand if I have non-OS specific files in the rpool.
Something that's *SIGNIFICANTLY* different than it won't work.
All the crazy things that you could do with old Cisco gear vs what TAC
would(n't) ""support you do comes to mind.
> Thanks, Cindy
Thank you Cindy.
> ROOT is just a mount-point structure. The lowercase root is the
> default home directory for the root (superuser) user.
I get the difference between "ROOT" as the base for the system and
"root" as the root user's home directory. To me, those are two
That doesn't give any indication why "ROOT" as the base for the system
Or are you saying that the capital was done to differentiate the two?
> See above. Create a separate pool for your data pool.
See above. That's not always a viable option.
> Again, just a mount point structure and also Solaris 11 has a lowercase
> root directory.
I'm trying to understand the history and motivation behind it being
named "ROOT", and specifically why it's capitals.
> I agree using caps is not very UNIX like.
There are plenty of commands that have options that use capital letters.
I believe there are even some commands that have capitals in their
name. (X11 related things come to mind.)
> I see a lowercase boot/solaris directory.
I wonder if the case difference is version related.
> rpool is for root pool, bpool looks like boot pool. The use of tank
> for a data pool name comes from the Matrix movie series. The ZFS eng
> team was keen on this movie series when ZFS was developed.
Thank you for your reply Cindy.