Setting up datasets and volumes

[oxyris]

Hello everyone,

I'm in the process of setting up my FreeNAS box. Currently I'm still testing to determine how best to setup my box for my needs.
I've chosen my volume type; I'll be using 6 disks in RAID-Z2 configuration. Now I want to setup some sort of folder structure on this volume for sharing in the network.

I was planning to have different datasets within my volume according to the type of data/media it should contain, e.g. Movies, Music, Pictures etc. To this end I wanted to simply "Create ZFS dataset" to my volume for each of the "folders" it should contain. In this way I could give different users distinct access to different "folders" (e.g. user A can access Movies and Music but not Pictures and user B can only access Pictures). Now I have two questions regarding this.

1) I this good idea to setup datasets? Or should datasets be chosen according to some other considerations?
2) I noticed that my volume also allows me to "Create ZFS volume" which creates a new volume under "/dev/zvol/[main volume]/[new volume]". However I cannot add datasets to this volume in the GUI. What is the purpose of this function (i.e. adding a volume to an existing volume)?

Many thanks.

 

[peterh]

A "dataset" in freenas parleance is what zfs folks call "a filesystem" , this may be
mounted locally and exported ( made visible ) through a network.

A "zfs volume" in freenas parleance is what zfs folks calls a "volume", a thing that
may be used as a raw or block device, typically an iscsi device.

What you probaby want is a filesystem ( dataset as freenas calls it) and it's i very nice way to administer your storage space.

The main idea goes like this : Pool your disks together into a "pool" choosing
the type of raid you want.
From this pool you create filesystem(s), as many as you like. Each filesystem
initially has the size of the free space in the pool. BUT, if you set "quota" for
a filesystem it will be used as size of that filesystem ( dataset). Thus you can
define your filesystems to sizes that you decide, hopefully adding up to less then
or equals your pool size. ( there is nothing preventing you assigning more space the
avaliable, this is approximatly the sme as "overbooking" practiced by airliners ( they
take a chance that all passangers that has a ticket won't show up, if they do they
will have to convince some of them to take next flight).
The really nice thing is that the quota you assign to each dataset can be changed
whenever you like. So the initial quota may be seen as a guess , later you may
transfer (unused)space from one filesystem to another.

Note however that zfs is unfriendly if you completley fill up a pool, you cannot even
delete files to recover space. Therefore it's better to have the assigned quotas be
less then pool size ( 80% is a thumb-rule)

 

[pete_c20]

@ peterh,
Thankyou for explaining this in more detail. It's verification of just what I'm looking for. I'm wanting to setup FreeNAS as a backup system, not as a server as such. I wanted to allocate about 80% of the available disk space for the dataset (on a recommendation for stability by jgreco in another post) but couldn't work out how the 'Reserved space for this dataset' & 'Reserved space for this dataset and all children' options worked in the 'Create ZFS Dataset' dialogue window. Allocating reserved space seems to produce a dataset larger than the original volume.

The reason for this is that I'm using the FreeNAS box with 2.6TB usable space, after volume creation, to backup a machine that has 2TB max. Many backup clients try to backup into a new subdirectory rather than performing a true file sync and so duplicate data. This is fine if your backup system is significantly larger than the source system and you have a low turnover of data.
Some clients such as QTDSync v0.6.18beta (using rsync) reinstate the 'backup into subdirectory' option every time a tree stucture has a directory added to it without you being fully aware of it. The danger in a system with a high data turnover is that the backup process would quickly fill the available space on the destination and actually outgrow the size of the source filespace. I do not want this.

So the solution to the problem, as I see it now, is to allocate 80% of the 2.6TB to the dataset (not try to do what I thought was the inverse of it which was to attempt to reserve about 20% for it) and if/when the backup runs away with itself it'll fall over by itself and I can fix it by temporarily enlarging the dataset size, deleting some off the destination, fixing the backup client setup, and then downsize the dataset again and resume the backup.

Can anybody see a flaw in that plan?