ZFS: managing filesystems

It’s been quite a while since I’ve cleared one of internal disks in my Netra t105 to bring it under ZFS control. As a result, I now have a 33Gb zfs-pool to experiment with. Today I had some spare time, so I decided to share with you the very basics of managing ZFS filesystems.

So this is the ZFS pool I have:

solaris# zpool list
NAME                    SIZE    USED   AVAIL    CAP  HEALTH     ALTROOT
stock                  33.8G   2.40G   31.4G     7%  ONLINE     -

And like I said, it has only one drive in it:

solaris# zpool status
pool: stock
state: ONLINE
scrub: scrub stopped with 0 errors on Tue Jan 17 21:00:45 2006
config:
NAME        STATE     READ WRITE CKSUM
stock       ONLINE       0     0     0
c0t1d0      ONLINE       0     0     0

By default, when you create a zfs-pool, all of its disk space is represented as a single filesystem with the same name. This filesystem also gets a mountpoint with the same name and is automatically mounted off /. So, after doing a zpool create (here is my example) you can immediately start working with your newly made filesystem.

At the moment I’ve got only 1 additional filesystem created, I use it for Oracle 10g. So here’s how it looks:

solaris# zfs list
NAME                   USED  AVAIL  REFER  MOUNTPOINT
stock                 2.40G  31.1G  8.50K  /stock
stock/oracle          2.32G   693M  2.32G  /stock/oracle

According to ZFS concepts, all the newly made filesystems may use all the available disk space of the zfs-pool they belong to. So, when I create another filesystem in my stock pool, this filesystem has more than 30Gb available to it:

solaris# zfs create stock/try
solaris# zfs list
NAME                   USED  AVAIL  REFER  MOUNTPOINT
stock                 2.40G  31.1G   9.5K  /stock
stock/oracle          2.32G   693M  2.32G  /stock/oracle
stock/try                8K  31.1G     8K  /stock/try

To make sure that some of your filesystems don’t eat up all the available disk space, you have to limit them. And it’s very easily done so:

solaris# zfs set quota=512m stock/try
solaris# zfs list
NAME                   USED  AVAIL  REFER  MOUNTPOINT
stock                 2.40G  31.1G   9.5K  /stock
stock/oracle          2.32G   693M  2.32G  /stock/oracle
stock/try                8K   512M     8K  /stock/try

As you have probably guessed, quota is the parameter name, while set is a keyword to alter parameters values. There is quite a number of ZFS filesystem parameters, and most of them you can modify, but there are also some which are read-only. Here's an example of such a parameter, and you can see what happens if you try modifying them:

solaris# zfs get mounted stock/try
NAME             PROPERTY       VALUE                      SOURCE
stock/try        mounted        yes                        -
solaris# zfs set mounted=on stock/try
cannot set mounted property: read-only property

You can find the full list of ZFS filesystem parameters on the man page for zfs, as for me – I’ll show you only 1 more parameter today, and a very useful one in my opinion: a mount point. As all the rest things about ZFS, this parameter is very easy to change, and you even have the filesystem automatically remounted for you:

solaris# df -k | grep ^stock
stock                 35112960       8 32597478     1%    /stock
stock/oracle           3145728 2436188   709540    78%    /stock/oracle
stock/try               524288       8   524280     1%    /stock/try
solaris# zfs set mountpoint=/try stock/try
solaris# df -k | grep ^stock
stock                 35112960       8 32597478     1%    /stock
stock/oracle           3145728 2436188   709540    78%    /stock/oracle
stock/try               524288       8   524280     1%    /try

I left the df output intentionally here, to show that there were no additional manipulations made to the try filesystem – it really is this easy!

I guess that’s enough for today – so next time I’ll tell you about few more useful ZFS filesystem parameters. Good luck with your experiments!