Skip to Content
Last modified by Drunk Monkey on 2024-09-01 12:05
From version 1.4
edited by Drunk Monkey
on 2024-09-01 12:04
Change comment: There is no comment for this version
To version 2.1
edited by Drunk Monkey
on 2024-09-01 12:05
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -6,8 +6,7 @@
6 6  
7 7  This is done by creating a redundant array of disks, and exporting a block device to represent that array. Then, we format that exported block device using LVM. If we have multiple RAID arrays, we format each of those as well. We then add all these exported block devices to a "volume group" which represents my pooled storage. If I had five exported RAID arrays, of 1 TB each, then I would have 5 TB of pooled storage in this volume group. Now, I need to decide how to divide up the volume, to create logical volumes of a specific size. If this was for an Ubuntu or Debian installation, maybe I would give 100 GB to one logical volume for the root filesystem. That 100 GB is now marked as occupied by the volume group. I then give 500 GB to my home directory, and so forth. Each operation exports a block device, representing my logical volume. It's these block devices that I format with ex4 or a filesystem of my choosing.
8 8  
9 -
10 -[[image:https://web.archive.org/web/20210430213505im_/http://pthree.org/wp-content/uploads/2012/12/lvm.png||alt="lvm" height="386" width="526"]]
9 +[[image:lvm.png||alt="lvm" height="386" width="526"]]
11 11  //Linux RAID, LVM, and filesystem stack. Each filesystem is limited in size.//
12 12  
13 13  
... ... @@ -15,8 +15,7 @@
15 15  
16 16  ZFS handles filesystems a bit differently. First, there is no need to create this stacked approach to storage. We've already covered how to pool the storage, now we well cover how to use it. This is done by creating a dataset in the filesystem. By default, this dataset will have full access to the entire storage pool. If our storage pool is 5 TB in size, as previously mentioned, then our first dataset will have access to all 5 TB in the pool. If I create a second dataset, it too will have full access to all 5 TB in the pool. And so on and so forth.
17 17  
18 -
19 -[[image:https://web.archive.org/web/20210430213505im_/http://pthree.org/wp-content/uploads/2012/12/zfs.png||alt="zfs" height="259" width="521"]]
17 +[[image:zfs.png||alt="zfs" height="259" width="521"]]
20 20  //Each ZFS dataset can use the full underlying storage.//
21 21  
22 22  
... ... @@ -28,15 +28,18 @@
28 28  
29 29  In these examples, we will assume our ZFS shared storage is named "tank". Further, we will assume that the pool is created with 4 preallocated files of 1 GB in size each, in a RAIDZ-1 array. Let's create some datasets.
30 30  
31 -{{code language="bash session"}}# zfs create tank/test
29 +{{code language="bash session"}}
30 +# zfs create tank/test
32 32  # zfs list
33 33  NAME USED AVAIL REFER MOUNTPOINT
34 34  tank 175K 2.92G 43.4K /tank
35 -tank/test 41.9K 2.92G 41.9K /tank/test{{/code}}
34 +tank/test 41.9K 2.92G 41.9K /tank/test
35 +{{/code}}
36 36  
37 37  Notice that the dataset "tank/test" is mounted to "/tank/test" by default, and that it has full access to the entire pool. Also notice that it is occupying only 41.9 KB of the pool. Let's create 4 more datasets, then look at the output:
38 38  
39 -{{code language="bash session"}}# zfs create tank/test2
39 +{{code language="bash session"}}
40 +# zfs create tank/test2
40 40  # zfs create tank/test3
41 41  # zfs create tank/test4
42 42  # zfs create tank/test5
... ... @@ -47,11 +47,13 @@
47 47  tank/test2 41.9K 2.92G 41.9K /tank/test2
48 48  tank/test3 41.9K 2.92G 41.9K /tank/test3
49 49  tank/test4 41.9K 2.92G 41.9K /tank/test4
50 -tank/test5 41.9K 2.92G 41.9K /tank/test5{{/code}}
51 +tank/test5 41.9K 2.92G 41.9K /tank/test5
52 +{{/code}}
51 51  
52 52  Each dataset is automatically mounted to its respective mount point, and each dataset has full unfettered access to the storage pool. Let's fill up some data in one of the datasets, and see how that affects the underlying storage:
53 53  
54 -{{code language="bash session"}}# cd /tank/test3
56 +{{code language="bash session"}}
57 +# cd /tank/test3
55 55  # for i in {1..10}; do dd if=/dev/urandom of=file$i.img bs=1024 count=$RANDOM &> /dev/null; done
56 56  # zfs list
57 57  NAME USED AVAIL REFER MOUNTPOINT
... ... @@ -60,7 +60,8 @@
60 60  tank/test2 41.9K 2.77G 41.9K /tank/test2
61 61  tank/test3 158M 2.77G 158M /tank/test3
62 62  tank/test4 41.9K 2.77G 41.9K /tank/test4
63 -tank/test5 41.9K 2.77G 41.9K /tank/test5{{/code}}
66 +tank/test5 41.9K 2.77G 41.9K /tank/test5
67 +{{/code}}
64 64  
65 65  Notice that in my case, "tank/test3" is occupying 158 MB of disk, so according to the rest of the datasets, there is only 2.77 GB available in the pool, where previously there was 2.92 GB. So as you can see, the big advantage here is that I do not need to worry about preallocated block devices, as I would with LVM. Instead, ZFS manages the entire stack, so it understands how much data has been occupied, and how much is available.
66 66  
... ... @@ -70,7 +70,8 @@
70 70  
71 71  So, if there is nothing to add do the /etc/fstab file, how do the filesystems get mounted? This is done by importing the pool, if necessary, then running the "zfs mount" command. Similarly, we have a "zfs unmount" command to unmount datasets, or we can use the standard "umount" utility:
72 72  
73 -{{code language="bash session"}}# umount /tank/test5
77 +{{code language="bash session"}}
78 +# umount /tank/test5
74 74  # mount | grep tank
75 75  tank/test on /tank/test type zfs (rw,relatime,xattr)
76 76  tank/test2 on /tank/test2 type zfs (rw,relatime,xattr)
... ... @@ -82,11 +82,13 @@
82 82  tank/test2 on /tank/test2 type zfs (rw,relatime,xattr)
83 83  tank/test3 on /tank/test3 type zfs (rw,relatime,xattr)
84 84  tank/test4 on /tank/test4 type zfs (rw,relatime,xattr)
85 -tank/test5 on /tank/test5 type zfs (rw,relatime,xattr){{/code}}
90 +tank/test5 on /tank/test5 type zfs (rw,relatime,xattr)
91 +{{/code}}
86 86  
87 87  By default, the mount point for the dataset is "/<pool-name>/<dataset-name>". This can be changed, by changing the dataset property. Just as storage pools have properties that can be tuned, so do datasets. We'll dedicate a full post to dataset properties later. We only need to change the "mountpoint" property, as follows:
88 88  
89 -{{code language="bash session"}}# zfs set mountpoint=/mnt/test tank/test
95 +{{code language="bash session"}}
96 +# zfs set mountpoint=/mnt/test tank/test
90 90  # mount | grep tank
91 91  tank on /tank type zfs (rw,relatime,xattr)
92 92  tank/test2 on /tank/test2 type zfs (rw,relatime,xattr)
... ... @@ -93,7 +93,8 @@
93 93  tank/test3 on /tank/test3 type zfs (rw,relatime,xattr)
94 94  tank/test4 on /tank/test4 type zfs (rw,relatime,xattr)
95 95  tank/test5 on /tank/test5 type zfs (rw,relatime,xattr)
96 -tank/test on /mnt/test type zfs (rw,relatime,xattr){{/code}}
103 +tank/test on /mnt/test type zfs (rw,relatime,xattr)
104 +{{/code}}
97 97  
98 98  == Nested Datasets ==
99 99  
... ... @@ -101,7 +101,8 @@
101 101  
102 102  To create a nested dataset, create it like you would any other, by providing the parent storage pool //and// dataset. In this case we will create a nested log dataset in the test dataset:
103 103  
104 -{{code language="bash session"}}# zfs create tank/test/log
112 +{{code language="bash session"}}
113 +# zfs create tank/test/log
105 105  # zfs list
106 106  NAME USED AVAIL REFER MOUNTPOINT
107 107  tank 159M 2.77G 47.9K /tank
... ... @@ -110,13 +110,15 @@
110 110  tank/test2 41.9K 2.77G 41.9K /tank/test2
111 111  tank/test3 158M 2.77G 158M /tank/test3
112 112  tank/test4 41.9K 2.77G 41.9K /tank/test4
113 -tank/test5 41.9K 2.77G 41.9K /tank/test5{{/code}}
122 +tank/test5 41.9K 2.77G 41.9K /tank/test5
123 +{{/code}}
114 114  
115 115  == Additional Dataset Administration ==
116 116  
117 117  Along with creating datasets, when you no longer need them, you can destroy them. This frees up the blocks for use by other datasets, and cannot be reverted without a previous snapshot, which we'll cover later. To destroy a dataset:
118 118  
119 -{{code language="bash session"}}# zfs destroy tank/test5
129 +{{code language="bash session"}}
130 +# zfs destroy tank/test5
120 120  # zfs list
121 121  NAME USED AVAIL REFER MOUNTPOINT
122 122  tank 159M 2.77G 49.4K /tank
... ... @@ -124,11 +124,13 @@
124 124  tank/test/log 41.9K 2.77G 41.9K /mnt/test/log
125 125  tank/test2 41.9K 2.77G 41.9K /tank/test2
126 126  tank/test3 158M 2.77G 158M /tank/test3
127 -tank/test4 41.9K 2.77G 41.9K /tank/test4{{/code}}
138 +tank/test4 41.9K 2.77G 41.9K /tank/test4
139 +{{/code}}
128 128  
129 129  We can also rename a dataset if needed. This is handy when the purpose of the dataset changes, and you want the name to reflect that purpose. The arguments take a dataset source as the first argument and the new name as the last argument. To rename the tank/test3 dataset to music:
130 130  
131 -{{code language="bash session"}}# zfs rename tank/test3 tank/music
143 +{{code language="bash session"}}
144 +# zfs rename tank/test3 tank/music
132 132  # zfs list
133 133  NAME USED AVAIL REFER MOUNTPOINT
134 134  tank 159M 2.77G 49.4K /tank
... ... @@ -136,7 +136,8 @@
136 136  tank/test 41.9K 2.77G 41.9K /mnt/test
137 137  tank/test/log 41.9K 2.77G 41.9K /mnt/test/log
138 138  tank/test2 41.9K 2.77G 41.9K /tank/test2
139 -tank/test4 41.9K 2.77G 41.9K /tank/test4{{/code}}
152 +tank/test4 41.9K 2.77G 41.9K /tank/test4
153 +{{/code}}
140 140  
141 141  == Conclusion ==
142 142  
lvm.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.pdwalker
Size
... ... @@ -1,0 +1,1 @@
1 +27.3 KB
Content
zfs.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.pdwalker
Size
... ... @@ -1,0 +1,1 @@
1 +17.7 KB
Content