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!