c27b2061fbeb44a3720dfd567fa463d1044b390d
[dragonfly.git] / sbin / hammer2 / hammer2.8
1 .\" Copyright (c) 2015 The DragonFly Project.  All rights reserved.
2 .\"
3 .\" This code is derived from software contributed to The DragonFly Project
4 .\" by Matthew Dillon <dillon@backplane.com>
5 .\"
6 .\" Redistribution and use in source and binary forms, with or without
7 .\" modification, are permitted provided that the following conditions
8 .\" are met:
9 .\"
10 .\" 1. Redistributions of source code must retain the above copyright
11 .\"    notice, this list of conditions and the following disclaimer.
12 .\" 2. Redistributions in binary form must reproduce the above copyright
13 .\"    notice, this list of conditions and the following disclaimer in
14 .\"    the documentation and/or other materials provided with the
15 .\"    distribution.
16 .\" 3. Neither the name of The DragonFly Project nor the names of its
17 .\"    contributors may be used to endorse or promote products derived
18 .\"    from this software without specific, prior written permission.
19 .\"
20 .\" THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
21 .\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
22 .\" LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
23 .\" FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE
24 .\" COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
25 .\" INCIDENTAL, SPECIAL, EXEMPLARY OR CONSEQUENTIAL DAMAGES (INCLUDING,
26 .\" BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
27 .\" LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
28 .\" AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
29 .\" OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
30 .\" OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
31 .\" SUCH DAMAGE.
32 .\"
33 .Dd March 26, 2015
34 .Dt HAMMER2 8
35 .Os
36 .Sh NAME
37 .Nm hammer2
38 .Nd hammer2 file system utility
39 .Sh SYNOPSIS
40 .Nm
41 .Fl h
42 .Nm
43 .Op Fl s Ar path
44 .Op Fl t Ar type
45 .Op Fl u Ar uuid
46 .Ar command
47 .Op Ar argument ...
48 .Sh DESCRIPTION
49 The
50 .Nm
51 utility provides miscellaneous support functions for a
52 HAMMER2 file system.
53 .Pp
54 The options are as follows:
55 .Bl -tag -width indent
56 .It Fl s Ar path
57 Specify the path to a mounted HAMMER2 filesystem.
58 At least one PFS on a HAMMER2 filesystem must be mounted for the system
59 to act on all PFSs managed by it.
60 Every HAMMER2 filesystem typically has a PFS called "LOCAL" for this purpose.
61 .It Fl t Ar type
62 Specify the type when creating, upgrading, or downgrading a PFS.
63 Supported types are MASTER, SLAVE, SOFT_MASTER, SOFT_SLAVE, CACHE, and DUMMY.
64 If not specified the pfs-create directive will default to MASTER if no
65 uuid is specified, and SLAVE if a uuid is specified.
66 .It Fl u Ar uuid
67 Specify the cluster uuid when creating a PFS.  If not specified, a unique,
68 random uuid will be generated.
69 Note that every PFS also has a unique pfs_id which is always generated
70 and cannot be overridden with an option.
71 The { pfs_clid, pfs_fsid } tuple uniquely identifies a component of a cluster.
72 .El
73 .Pp
74 .Nm
75 directives are as shown below.
76 Note that most directives require you to either be CD'd into a hammer2
77 filesystem, specify a path to a mounted hammer2 filesystem via the
78 .Fl s
79 option, or specify a path after the directive.
80 It depends on the directive.
81 All hammer2 filesystem have a PFS called "LOCAL" which is typically mounted
82 locally on the host in order to be able to issue commands for other PFSs
83 on the filesystem.
84 The mount also enables PFS configuration scanning for that filesystem.
85 .Bl -tag -width indent
86 .\" ==== connect ====
87 .It Cm connect Ar target
88 Add a cluster link entry to the volume header.
89 The volume header can support up to 255 link entries.
90 This feature is not currently used.
91 .\" ==== disconnect ====
92 .It Cm disconnect Ar target
93 Delete a cluster link entry from the volume header.
94 This feature is not currently used.
95 .\" ==== info ====
96 .It Cm info Op devpath
97 Access and print the status and super-root entries for all HAMMER2
98 partitions found in /dev/serno or the specified device path(s).
99 The partitions do not have to be mounted.
100 Note that only mounted partitions will be under active management.
101 This is accomplished by mounting at least one PFS within the partition.
102 Typically at least the @LOCAL PFS is mounted.
103 .\" ==== mountall ====
104 .It Cm mountall Op devpath
105 This directive mounts the @LOCAL PFS on all HAMMER2 partitions found
106 in /dev/serno, or the specified device path(s).
107 The partitions are mounted as /var/hammer2/LOCAL.<id>.
108 Mounts are executed in the background and this command will wait a
109 limited amount of time for the mounts to complete before returning.
110 .\" ==== status ====
111 .It Cm status Ar path...
112 Dump a list of all cluster link entries configured in the volume header.
113 .\" ==== hash ====
114 .It Cm hash Ar filename...
115 Compute and print the directory hash for any number of filenames.
116 .\" ==== pfs-list ====
117 .It Cm pfs-list Op path...
118 List all local PFSs available on a mounted HAMMER2 filesystem, their type,
119 and their current status.
120 You must mount at least one PFS in order to be able to access the whole list.
121 .\" ==== pfs-clid ====
122 .It Cm pfs-clid Ar label
123 Print the cluster id for a PFS specified by name.
124 .\" ==== pfs-fsid ====
125 .It Cm pfs-fsid Ar label
126 Print the unique filesystem id for a PFS specified by name.
127 .\" ==== pfs-create ====
128 .It Cm pfs-create Ar label
129 Create a local PFS on a mounted HAMMER2 filesystem.
130 If no uuid is specified the pfs-type defaults to MASTER.
131 If a uuid is specified via the
132 .Fl u
133 option the pfs-type defaults to SLAVE.
134 Other types can be specified with the
135 .Fl t
136 option.
137 .Pp
138 If you wish to add a MASTER to an existing cluster, you must first add it as
139 a SLAVE and then upgrade it to MASTER to properly synchronize it.
140 .Pp
141 The DUMMY pfs-type is used to tie network-accessible clusters into the local
142 machine when no local storage is desired.
143 This type should be used on minimal H2 partitions or entirely in ram for
144 netboot-centric systems to provide a tie-in point for the mount command,
145 or on more complex systems where you need to also access network-centric
146 clusters.
147 .Pp
148 The CACHE or SLAVE pfs-type is typically used when the main store is on
149 the network but local storage is desired to improve performance.
150 SLAVE is also used when a backup is desired.
151 .Pp
152 Generally speaking, you can mount any PFS element of a cluster in order to
153 access the cluster via the full cluster protocol.
154 There are two exceptions.
155 If you mount a SOFT_SLAVE or a SOFT_MASTER then soft quorum semantics are
156 employed... the soft slave or soft master's current state will always be used
157 and the quorum protocol will not be used.  The soft PFS will still be
158 synchronized to masters in the background when available.
159 Also, you can use 'mount -o local' to mount ONLY a local HAMMER2 PFS and
160 not run any network or quorum protocols for the mount.
161 All such mounts except for a SOFT_MASTER mount will be read-only.
162 Other than that, you will be mounting the whole cluster when you mount any
163 PFS within the cluster.
164 .Pp
165 DUMMY - Create a PFS skeleton intended to be the mount point for a
166 more complex cluster, probably one that is entirely network based.
167 No data will be synchronized to this PFS so it is suitable for use
168 in a network boot image or memory filesystem.
169 This allows you to create placeholders for mount points on your local
170 disk, SSD, or memory disk.
171 .Pp
172 CACHE - Create a PFS for caching portions of the cluster piecemeal.
173 This is similar to a SLAVE but does not synchronize the entire contents of
174 the cluster to the PFS.
175 Elements found in the CACHE PFS which are validated against the cluster
176 will be read, presumably a faster access than having to go to the cluster.
177 Only local CACHEs will be updated.
178 Network-accessible CACHE PFSs might be read but will not be written to.
179 If you have a large hard-drive-based cluster you can set up localized
180 SSD CACHE PFSs to improve performance.
181 .Pp
182 SLAVE - Create a PFS which maintains synchronization with and provides a
183 read-only copy of the cluster.
184 HAMMER2 will prioritize local SLAVEs for data retrieval after validating
185 their transaction id against the cluster.
186 The difference between a CACHE and a SLAVE is that the SLAVE is synchronized
187 to a full copy of the cluster and thus can serve as a backup or be staged
188 for use as a MASTER later on.
189 .Pp
190 SOFT_SLAVE - Create a PFS which maintains synchronization with and provides
191 a read-only copy of the cluster.
192 This is one of the special mount cases.  A SOFT_SLAVE will synchronize with
193 the cluster when the cluster is available, but can still be accessed when
194 the cluster is not available.
195 .Pp
196 MASTER - Create a PFS which will hold a master copy of the cluster.
197 If you create several MASTER PFSs with the same cluster id you are
198 effectively creating a multi-master cluster and causing a quorum and
199 cache coherency protocol to be used to validate operations.
200 The total number of masters is stored in each PFSs making up the cluster.
201 Filesystem operations will stall for normal mounts if a quorum cannot be
202 obtained to validate the operation.
203 MASTER nodes which go offline and return later will synchronize in the
204 background.
205 Note that when adding a MASTER to an existing cluster you must add the
206 new PFS as a SLAVE and then upgrade it to a MASTER.
207 .Pp
208 SOFT_MASTER - Create a PFS which maintains synchronization with and provides
209 a read-write copy of the cluster.
210 This is one of the special mount cases.  A SOFT_MASTER will synchronize with
211 the cluster when the cluster is available, but can still be read AND written
212 to even when the cluster is not available.
213 Modifications made to a SOFT_MASTER will be automatically flushed to the
214 cluster when it becomes accessible again, and vise-versa.
215 Manual intervention may be required if a conflict occurs during
216 synchronization.
217 .\" ==== pfs-delete ====
218 .It Cm pfs-delete Ar label
219 Delete a local PFS on a mounted HAMMER2 filesystem.
220 Deleting a PFS of type MASTER requires first downgrading it to a SLAVE (XXX).
221 .\" ==== snapshot ====
222 .It Cm snapshot Ar path Op label
223 Create a snapshot of a directory.
224 This can only be used on a local PFS, and is only really useful if the PFS
225 contains a complete copy of what you desire to snapshot so that typically
226 means a local MASTER, SOFT_MASTER, SLAVE, or SOFT_SLAVE must be present.
227 Snapshots are created simply by flushing a PFS mount to disk and then copying
228 the directory inode to the PFS.
229 The topology is snapshotted without having to be copied or scanned.
230 Snapshots are effectively separate from the cluster they came from
231 and can be used as a starting point for a new cluster.
232 So unless you build a new cluster from the snapshot, it will stay local
233 to the machine it was made on.
234 .\" ==== service ====
235 .It Cm service
236 Start the
237 .Nm
238 service daemon.
239 This daemon is also automatically started when you run
240 .Xr mount_hammer2 8 .
241 The hammer2 service daemon handles incoming TCP connections and maintains
242 outgoing TCP connections.  It will interconnect available services on the
243 machine (e.g. hammer2 mounts and xdisks) to the network.
244 .\" ==== stat ====
245 .It Cm stat Op path...
246 Print the inode statistics, compression, and other meta-data associated
247 with a list of paths.
248 .\" ==== leaf ====
249 .It Cm leaf
250 XXX
251 .\" ==== shell ====
252 .It Cm shell
253 Start a debug shell to the local hammer2 service daemon via the DMSG protocol.
254 .\" ==== debugspan ====
255 .It Cm debugspan
256 (do not use)
257 .\" ==== rsainit ====
258 .It Cm rsainit
259 Create the
260 .Pa /etc/hammer2
261 directory and initialize a public/private keypair in that directory for
262 use by the network cluster protocols.
263 .\" ==== show ====
264 .It Cm show Ar devpath
265 Dump the radix tree for the HAMMER2 filesystem by scanning a
266 block device directly.  No mount is required.
267 .\" ==== freemap ====
268 Dump the freemap tree for the HAMMER2 filesystem by scanning a
269 block device directly.  No mount is required.
270 .It Cm freemap Ar devpath
271 .\" ==== setcomp ====
272 .It Cm setcomp Ar mode[:level] Op path...
273 Set the compression mode as specified for any newly created elements at or
274 under the path if not overridden by deeper elements.
275 Available modes are none, autozero, lz4, or zlib.
276 When zlib is used the compression level can be set.
277 The default will be 6 which is the best trade-off between performance and
278 time.
279 .Pp
280 newfs_hammer2 will set the default compression to lz4 which prioritizes
281 speed over performance.
282 Also note that HAMMER2 contains a heuristic and will not attempt to
283 compress every block if it detects a sufficient amount of uncompressable
284 data.
285 .Pp
286 Hammer2 compression is only effective when it can reduce the size of dataset
287 (typically a 64KB block) by one or more powers of 2.  A 64K block which
288 only compresses to 40K will not yield any storage improvement.
289 .Pp
290 Generally speaking you do not want to set the compression mode to 'none',
291 as this will cause blocks of all-zeros to be written as all-zero blocks,
292 instead of holes.  The 'autozero' compression mode detects blocks of all-zeros
293 and writes them as holes.  However, HAMMER2 will rewrite data in-place if
294 the compression mode is set to 'none' and the check code is set to
295 'disabled'.  Formal snapshots will still snapshot such files.  However,
296 de-duplication will no longer function on the data blocks.
297 .\" ==== setcheck ====
298 .It Cm setcheck Ar check Op path...
299 Set the check code as specified for any newly created elements at or under
300 the path if not overridden by deeper elements.
301 Available codes are default, disabled, crc32, xxhash64, or sha192.
302 .\" ==== clrcheck ====
303 .It Cm clrcheck Op path...
304 Clear the check code override for the specified paths.
305 Overrides may still be present in deeper elements.
306 .\" ==== setcrc32 ====
307 .It Cm setcrc32 Op path...
308 Set the check code to the ISCSI 32-bit CRC for any newly created elements
309 at or under the path if not overridden by deeper elements.
310 .\" ==== setxxhash64 ====
311 .It Cm setxxhash64 Op path...
312 Set the check code to XXHASH64, a fast 64-bit hash
313 .\" ==== setsha192 ====
314 .It Cm setsha192 Op path...
315 Set the check code to SHA192 for any newly created elements at or under
316 the path if not overridden by deeper elements.
317 .\" ==== bulkfree ====
318 .It Cm bulkfree Op path...
319 Run a bulkfree pass on a HAMMER2 mount.
320 You can specify any PFS for the mount, the bulkfree pass is run on the
321 entire partition.
322 Note that it takes two passes to actually free space.
323 .El
324 .Sh SYSCTLS
325 .Bl -tag -width indent
326 .It Va vfs.hammer2.dedup_enable (default on)
327 Enables live de-duplication.  Any recently read data that is on-media
328 (already synchronized to media) is tested against pending writes for
329 compatibility.  If a match is found, the write will reference the
330 existing on-media data instead of writing new data.
331 .It Va vfs.hammer2.always_compress (default off)
332 This disables the H2 compression heuristic and forces H2 to always
333 try to compress data blocks, even if they look uncompressable.
334 Enabling this option reduces performance but has higher de-duplication
335 repeatability.
336 .It Va vfs.hammer2.cluster_data_read (default 4)
337 .It Va vfs.hammer2.cluster_meta_read (default 1)
338 Set the amount of read-ahead clustering to perform on data and meta-data
339 blocks.
340 .It Va vfs.hammer2.cluster_write (default 0)
341 Set the amount of write-behind clustering to perform.  This is disabled by
342 default in order to give temporary files a chance to be deleted before
343 media writes are committed.  Enabling this reduces buffer cache stress
344 but causes file writes to flush to media more quickly.
345 .It Va vfs.hammer2.bulkfree_tps (default 5000)
346 Set bulkfree's maximum scan rate.  This is primarily intended to limit
347 I/O utilization on SSDs and cpu utilization when the meta-data is mostly
348 cached in memory.
349 .El
350 .Sh SETTING UP /etc/hammer2
351 The 'rsainit' directive will create the
352 .Pa /etc/hammer2
353 directory with appropriate permissions and also generate a public key
354 pair in this directory for the machine.  These files will be
355 .Pa rsa.pub
356 and
357 .Pa rsa.prv
358 and needless to say, the private key shouldn't leave the host.
359 .Pp
360 The service daemon will also scan the
361 .Pa /etc/hammer2/autoconn
362 file which contains a list of hosts which it will automatically maintain
363 connections to to form your cluster.
364 The service daemon will automatically reconnect on any failure and will
365 also monitor the file for changes.
366 .Pp
367 When the service daemon receives a connection it expects to find a
368 public key for that connection in a file in
369 .Pa /etc/hammer2/remote/
370 called
371 .Pa <IPADDR>.pub .
372 You normally copy the
373 .Pa rsa.pub
374 key from the host in question to this file.
375 The IP address must match exactly or the connection will not be allowed.
376 .Pp
377 If you want to use an unencrypted connection you can create empty,
378 dummy files in the remote directory in the form
379 .Pa <IPADDR>.none .
380 We do not recommend using unencrypted connections.
381 .Sh CLUSTER SERVICES
382 Currently there are two services which use the cluster network infrastructure,
383 HAMMER2 mounts and XDISK.
384 Any HAMMER2 mount will make all PFSs for that filesystem available to the
385 cluster.
386 And if the XDISK kernel module is loaded, the hammer2 service daemon will make
387 your machine's block devices available to the cluster (you must load the
388 xdisk.ko kernel module before starting the hammer2 service).
389 They will show up as
390 .Pa /dev/xa*
391 and
392 .Pa /dev/serno/*
393 devices on the remote machines making up the cluster.
394 Remote block devices are just what they appear to be... direct access to a
395 block device on a remote machine.  If the link goes down remote accesses
396 will stall until it comes back up again, then automatically requeue any
397 pending I/O and resume as if nothing happened.
398 However, if the server hosting the physical disks crashes or is rebooted,
399 any remote opens to its devices will see a permanent I/O failure requiring a
400 close and open sequence to re-establish.
401 The latter is necessary because the server's drives might not have committed
402 the data before the crash, but had already acknowledged the transfer.
403 .Pp
404 Data commits work exactly the same as they do for real block devices.
405 The originater must issue a BUF_CMD_FLUSH.
406 .Sh ADDING A NEW MASTER TO A CLUSTER
407 When you
408 .Xr newfs_hammer2 8
409 a HAMMER2 filesystem or use the 'pfs-create' directive on one already mounted
410 to create a new PFS, with no special options, you wind up with a PFS
411 typed as a MASTER and a unique cluster uuid, but because there is only one
412 PFS for that cluster (for each PFS you create via pfs-create), it will
413 act just like a normal filesystem would act and does not require any special
414 protocols to operate.
415 .Pp
416 If you use the 'pfs-create' directive along with the
417 .Fl u
418 option to specify a cluster uuid that already exists in the cluster,
419 you are adding a PFS to an existing cluster and this can trigger a whole
420 series of events in the background.
421 When you specify the
422 .Fl u
423 option in a 'pfs-create',
424 .Nm
425 will by default create a SLAVE PFS.
426 In fact, this is what must be created first even if you want to add a new
427 MASTER to your cluster.
428 .Pp
429 The most common action a system admin will want to take is to upgrade or
430 downgrade a PFS.
431 A new MASTER can be added to the cluster by upgrading an existing SLAVE
432 to MASTER.
433 A MASTER can be removed from the cluster by downgrading it to a SLAVE.
434 Upgrades and downgrades will put nodes in the cluster in a transition state
435 until the operation is complete.
436 For downgrades the transition state is fleeting unless one or more other
437 masters has not acknowledged the change.
438 For upgrades a background synchronization process must complete before the
439 transition can be said to be complete, and the node remains (really) a SLAVE
440 until that transition is complete.
441 .Sh USE CASES FOR A SOFT_MASTER
442 The SOFT_MASTER PFS type is a special type which must be specifically
443 mounted by a machine.
444 It is a R/W mount which does not use the quorum protocol and is not
445 cache coherent with the cluster, but which synchronizes from the cluster
446 and allows modifying operations which will synchronize to the cluster.
447 The most common case is to use a SOFT_MASTER PFS in a laptop allowing you
448 to work on your laptop when you are on the road and not connected to
449 your main servers, and for the laptop to synchronize when a connection is
450 available.
451 .Sh USE CASES FOR A SOFT_SLAVE
452 A SOFT_SLAVE PFS type is a special type which must be specifically mounted
453 by a machine.
454 It is a RO mount which does not use the quorum protocol and is not
455 cache coherent with the cluster.  It will receive synchronization from
456 the cluster when network connectivity is available but will not stall if
457 network connectivity is lost.
458 .Sh FSYNC FLUSH MODES
459 TODO.
460 .Sh RESTORING FROM A SNAPSHOT BACKUP
461 TODO.
462 .Sh PERFORMANCE TUNING
463 Because HAMMER2 implements compression, decompression, and deup natively,
464 it always double-buffers file data.  This means that the file data is
465 cached via the device vnode (in compressed / dedupped-form) and the same
466 data is also cached by the file vnode (in decompressed / non-dedupped form).
467 .Pp
468 While HAMMER2 will try to age the logical file buffers on its, some
469 additional performance tuning may be necessary for optimal operation
470 whether swapcache is used or not.  Our recommendation is to reduce the
471 number of vnodes (and thus also the logical buffer cache behind the
472 vnodes) that the system caches via the
473 .Va kern.maxvnodes
474 sysctl.
475 .Pp
476 Too-large a value will result in excessive double-caching and can cause
477 unnecessary read disk I/O.
478 We recommend a number between 25000 and 250000 vnodes, depending on your
479 use case.
480 Keep in mind that even though the vnode cache is smaller, this will make
481 room for a great deal more device-level buffer caching which can encompasses
482 far more data and meta-data than the vnode-level caching.
483 .Sh ENVIRONMENT
484 TODO.
485 .Sh FILES
486 .Bl -tag -width ".It Pa <fs>/abc/defghi/<name>" -compact
487 .It Pa /etc/hammer2/
488 .It Pa /etc/hammer2/rsa.pub
489 .It Pa /etc/hammer2/rsa.prv
490 .It Pa /etc/hammer2/autoconn
491 .It Pa /etc/hammer2/remote/<IP>.pub
492 .It Pa /etc/hammer2/remote/<IP>.none
493 .El
494 .Sh EXIT STATUS
495 .Ex -std
496 .Sh SEE ALSO
497 .Xr mount_hammer2 8 ,
498 .Xr mount_null 8 ,
499 .Xr newfs_hammer2 8 ,
500 .Xr swapcache 8 ,
501 .Xr sysctl 8
502 .Sh HISTORY
503 The
504 .Nm
505 utility first appeared in
506 .Dx 4.1 .
507 .Sh AUTHORS
508 .An Matthew Dillon Aq Mt dillon@backplane.com