1

I have created a pool in zfs using:

zpool create data001 mirror /dev/sda /dev/sdb

but in hindsight I wanted to create

zpool create data/001 mirror /dev/sda /dev/sdb

None of the rename/move options I've found work because 'data' doesn't exist, but I can't create 'data' since it doesn't seem to be meaningful to create a pool that has no devices.

2 Answers 2

1

I'm pretty sure you mean "zpool create" not "zfs create" for the first one. So here's what you should do:

# zpool create data mirror /dev/sda /dev/sdb
# zfs create data/001

The first command will get you your "data" pool, plus the /data filesystem, and the second command will create the /data/001 filesystem.

4
  • Is this the set of commands I should have run, or can still, while preserving data? The first line looks like it would make a new pool over the top of the existing. I am new to zfs and find the split of functionality between zfs and zpool seems arbitrary, likely because of some misunderstanding of the technology.
    – J Collins
    Commented Nov 8, 2016 at 9:29
  • You can still do this, by renaming the pool. A "zpool export data001" followed by "zpool import data001 data" will rename the pool from data001 to data.
    – mmusante
    Commented Nov 8, 2016 at 14:51
  • That works to rename it to 'data', but not to 'data/001', right?
    – J Collins
    Commented Nov 8, 2016 at 15:46
  • Right. You can then address the data -> data/001 issue by "zfs create data/001" and then using mv or zfs send|zfs recv
    – mmusante
    Commented Nov 9, 2016 at 12:05
1

zpool create data mirror /dev/sda /dev/sdb

zfs create data/001

Is this the set of commands I should have run, or can still, while preserving data? The first line looks like it would make a new pool over the top of the existing.

This is what you should have done. Doing it now will just tell you that it is not possible to use disks that are already part of a pool for a new pool without destroying the old one or removing the disks from it (except the last one, not possible if using raidz instead of mirrors). It may also be a good point to think about your backup strategy, if you don't have one.


I am new to zfs and find the split of functionality between zfs and zpool seems arbitrary, likely because of some misunderstanding of the technology

Oracle has a detailed guide to how you use pools and file systems, and there are also some condensed best practices. To sum it up in really broad terms, there a three layers:

  1. You build virtual devices (vdevs) from normal devices (normally disks, can also be files or partitions) with a certain redundancy feature (basic, mirrors, or raidz).
  2. You build storage pools (zpools) from multiple vdevs, which are always striped (concatenated) and offer you the summed size of those vdevs as continuous storage.
  3. You create either file systems or zvols inside those pools. File systems can be nested inside each other. In theory the pool itself is also writable, but it is recommended to not do this because of easier management/property inheritance.

My personal recommendations for those layers:

  1. Use disks of same size, speed and quality for each vdev. Prefer mirrors as they are more flexible and faster than raidz. Avoid basic vdevs because they can kill your whole pool if one fails.
  2. Create storage pools for similar vdevs, for example one pool with SSD vdevs (mirrors) for VM storage and one pool with HDD vdevs (raidz2) for slower but bigger backup storage. Combining them would make the pool as slow as the HDD and as dangerous as the single mirror for ALL data, so it is not a good idea.
  3. Create as many file systems as you like and use inheritance to manage them easily (properties like SMB or NFS share can be inherited the same way as quotas or general ACL settings). Your design depends on your organization and structure, but common rules are "one filesystem for each user home directory" and "one filesystem for each independent network share". Avoid splitting filesystems up if the content inside is essentially about the same topic, but moving is frequent, as inter-filesystem move is always a full and costly operation, even on the same pool. You need zvols only if you export block storage or with KVM, so start simple (filesystems can also be used as block storage).
  4. Use directories inside the file systems as you usually would (set ACLs, segregate data etc.).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .