Is it a pool or file system?

Status
Not open for further replies.

hua_qiu

Cadet
Joined
Apr 28, 2015
Messages
9
Please forgive me if this is a dump question. But after using ZFS for over 8 years I still confused. Here is my question

Let's create a zpool as
zpool create tank c1t0d0 c1t1d0

My understanding is that there were actually two objects created in this command
1. A zpool named "tank"
2. A file system name "tank", too

Evidently, the file system "tank" is mounted and you can copy files into it. However, I have never found any official document describe such behavior. Can somebody confirm my understanding is correct?

Further, all examples given from official document in relate to operation on file system are in the form such as, tank/home. The explanation given refer "tank" as zpool and "home" as file system(data set). So if there is indeed a default file system created alone with pool creation, won't it be more logical and consistent to refer to "tank" as file system. Effectively, "home" is a nested file system within the file system "tank", which is the default file system on zpool "tank"?

Many thanks
 
Last edited by a moderator:

Stux

MVP
Joined
Jun 2, 2016
Messages
4,358
I think there is an implicit dataset on the pool. And that dataset is mounted as a file system.

You can then create other datasets or zvols (ie a block device) which can be mounted, or treated as a block device, respectively.
 

hua_qiu

Cadet
Joined
Apr 28, 2015
Messages
9
I found my answer. Here is the quote from FreeBSD manual page zfs(8), which is re-implemented from OpenSolaris material. I would consider it is quasi-official.

A storage pool is also the root of the ZFS file system
hierarchy.

The root of the pool can be accessed as a file system, such as mounting
and unmounting, taking snapshots, and setting properties. The physical
storage characteristics, however, are managed by the zpool(8) command.

This kind of confirmed the existence of the implicit dataset as well as what kind of operation the implicit dataset supports. However, I am still wonder why the ZFS architect didn't give a more formal name/reference of such dataset, e.g. root file system or root dataset, etc
 

Ericloewe

Server Wrangler
Moderator
Joined
Feb 15, 2014
Messages
20,175
It is the root dataset and it always has the same name as the pool backing it. It supports pretty much everything any dataset supports, though some things may ruin your day if applied to the root dataset in something like a FreeNAS server.

I get the feeling that you're thinking about it in the old way: Volume manager and then a filesystem. Since ZFS integrates them both, the distinction does not exist - a pool without datasets is useless and a dataset needs an underlying pool.
 

hua_qiu

Cadet
Joined
Apr 28, 2015
Messages
9
Thanks for your thoughts, Ericloewe. However old way or new way it must be consistent. I fail to see the rational of creating a implicit (default) file system on the zpool. Hypothetically, one can create a zpool solely used to host zvol. In the case the implicit file system is unnecessary and redundant.

From purist point of view it is a flaw in architecture design.
 

hua_qiu

Cadet
Joined
Apr 28, 2015
Messages
9
with all due respect, I never said it is not a zpool, rather the design decision to create an implicit(mandatory) file system on top of the zpool. Before I fork out $9.57, just wonder which chapter in the book explains such design decision and rational behind it?
 

Arwen

MVP
Joined
May 17, 2014
Messages
3,600
Thanks for your thoughts, Ericloewe. However old way or new way it must be consistent. I fail to see the rational of creating a implicit (default) file system on the zpool. Hypothetically, one can create a zpool solely used to host zvol. In the case the implicit file system is unnecessary and redundant.

From purist point of view it is a flaw in architecture design.
In a way, I agree.

However, having an implicit parent / root dataset has uses. Specifically I can set compression, ACL features and other features, (to datasets, not pools). Those are then inherited by all children datasets.
 

Stux

MVP
Joined
Jun 2, 2016
Messages
4,358
Also, say you wanted to add another zvol one day. How would you if the root was the zvol?

You couldn't move the original one, because there was no where to move it.

A zvol is always in a dataset, be it the root one or another and can be moved trivially.
 

hua_qiu

Cadet
Joined
Apr 28, 2015
Messages
9
In a way, I agree.

However, having an implicit parent / root dataset has uses. Specifically I can set compression, ACL features and other features, (to datasets, not pools). Those are then inherited by all children datasets.

Agree this is a good practice should be encouraged. But again there is no need to implement a full file system just for the sake of enable attributes inheritance.

For the matter of fact the existence of implicit file system is conveniently omitted in most of the admin guide tells something. Maybe they themselves also worried this may confuse a lot or being criticized by some like me. I don't know.

Logically if this is such grand design, what stops them being more upfront about it, such as, "hey, btw, there is also a file system created along with the zpool tank. you can set ACL, compression, etc. It is best practice because ...."

Last, please don't get me wrong. As I mentioned I have been using ZFS for long time on various OS. I do think it is revolutionary file system in its time.
 

Arwen

MVP
Joined
May 17, 2014
Messages
3,600
Agree this is a good practice should be encouraged. But again there is no need to implement a full file system just for the sake of enable attributes inheritance.

For the matter of fact the existence of implicit file system is conveniently omitted in most of the admin guide tells something. Maybe they themselves also worried this may confuse a lot or being criticized by some like me. I don't know.

Logically if this is such grand design, what stops them being more upfront about it, such as, "hey, btw, there is also a file system created along with the zpool tank. you can set ACL, compression, etc. It is best practice because ...."

Last, please don't get me wrong. As I mentioned I have been using ZFS for long time on various OS. I do think it is revolutionary file system in its time.
In a way, it's my best practice to use something like this on Linux;

rpool/root
rpool/root/YYYYMMDD
rpool/root/YYYYMMDD
rpoo/home
rpool/src
rpool/src/4.9.16
rpool/src/4.9.34
rpool/htdocs
rpool/`hostname`
rpool/Media
rpool/backups

Solaris does something somewhat similar. I keep multiple root environments based on dates, (using snapshots and clones, not shown above). Plus, I may make multiple Linux kernels, of the same parent version, also using snapshots and clones. All in case I need to go back in history. (It's just too easy for snapshots and clones, compared to restores.)

So I really never use the base / parent dataset except to set the ZFS parameters I want on the children datasets. Even for the Media data I allow the inherited compression, since it's pretty harmless. (Meaning it takes little extra time to write, and does not cause the compression ratio to go negative.)

In regards to creating a pool with the base / parent dataset's attributes pre-set, it's actually part of the zpool command;

zpool create -o ashift=12 -O compression=lz4 rpool mirror sda1 sdb1

Where the lower case o is used for the pool attributes and the uppercase O is used for the base / parent dataset's attributes.
 

Ericloewe

Server Wrangler
Moderator
Joined
Feb 15, 2014
Messages
20,175
I think we're losing sight of the "FS" part of "ZFS".

Hypothetically, one can create a zpool solely used to host zvol.
Which is probably the only situation that doesn't benefit from the root dataset. And it's still completely harmless.
Wanting to use two commands instead of one to get a working pool is akin to fighting for your right to a rm -rf / that destroys your entire system.
 
Status
Not open for further replies.
Top