xref: /dragonfly/sys/vfs/hammer2/hammer2_disk.h (revision c93b565c)

/*
 * Copyright (c) 2011-2014 The DragonFly Project.  All rights reserved.
 *
 * This code is derived from software contributed to The DragonFly Project
 * by Matthew Dillon <dillon@dragonflybsd.org>
 * by Venkatesh Srinivas <vsrinivas@dragonflybsd.org>
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in
 *    the documentation and/or other materials provided with the
 *    distribution.
 * 3. Neither the name of The DragonFly Project nor the names of its
 *    contributors may be used to endorse or promote products derived
 *    from this software without specific, prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
 * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
 * FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE
 * COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
 * INCIDENTAL, SPECIAL, EXEMPLARY OR CONSEQUENTIAL DAMAGES (INCLUDING,
 * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
 * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
 * AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
 * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 */

#ifndef _VFS_HAMMER2_DISK_H_
#define _VFS_HAMMER2_DISK_H_

#ifndef _SYS_UUID_H_
#include <sys/uuid.h>
#endif
#ifndef _SYS_DMSG_H_
#include <sys/dmsg.h>
#endif

/*
 * The structures below represent the on-disk media structures for the HAMMER2
 * filesystem.  Note that all fields for on-disk structures are naturally
 * aligned.  The host endian format is typically used - compatibility is
 * possible if the implementation detects reversed endian and adjusts accesses
 * accordingly.
 *
 * HAMMER2 primarily revolves around the directory topology:  inodes,
 * directory entries, and block tables.  Block device buffer cache buffers
 * are always 64KB.  Logical file buffers are typically 16KB.  All data
 * references utilize 64-bit byte offsets.
 *
 * Free block management is handled independently using blocks reserved by
 * the media topology.
 */

/*
 * The data at the end of a file or directory may be a fragment in order
 * to optimize storage efficiency.  The minimum fragment size is 1KB.
 * Since allocations are in powers of 2 fragments must also be sized in
 * powers of 2 (1024, 2048, ... 65536).
 *
 * For the moment the maximum allocation size is HAMMER2_PBUFSIZE (64K),
 * which is 2^16.  Larger extents may be supported in the future.  Smaller
 * fragments might be supported in the future (down to 64 bytes is possible),
 * but probably will not be.
 *
 * A full indirect block use supports 1024 x 64-byte blockrefs in a 64KB
 * buffer.  Indirect blocks down to 1KB are supported to keep small
 * directories small.
 *
 * A maximally sized file (2^64-1 bytes) requires 5 indirect block levels.
 * The hammer2_blockset in the volume header or file inode has another 8
 * entries, giving us 66+3 = 69 bits of address space.  However, some bits
 * are taken up by (potentially) requests for redundant copies.  HAMMER2
 * currently supports up to 8 copies, which brings the address space down
 * to 66 bits and gives us 2 bits of leeway.
 */
#define HAMMER2_ALLOC_MIN	1024	/* minimum allocation size */
#define HAMMER2_RADIX_MIN	10	/* minimum allocation size 2^N */
#define HAMMER2_ALLOC_MAX	65536	/* maximum allocation size */
#define HAMMER2_RADIX_MAX	16	/* maximum allocation size 2^N */
#define HAMMER2_RADIX_KEY	64	/* number of bits in key */

/*
 * MINALLOCSIZE		- The minimum allocation size.  This can be smaller
 *		  	  or larger than the minimum physical IO size.
 *
 *			  NOTE: Should not be larger than 1K since inodes
 *				are 1K.
 *
 * MINIOSIZE		- The minimum IO size.  This must be less than
 *			  or equal to HAMMER2_LBUFSIZE.
 *
 * HAMMER2_LBUFSIZE	- Nominal buffer size for I/O rollups.
 *
 * HAMMER2_PBUFSIZE	- Topological block size used by files for all
 *			  blocks except the block straddling EOF.
 *
 * HAMMER2_SEGSIZE	- Allocation map segment size, typically 2MB
 *			  (space represented by a level0 bitmap).
 */

#define HAMMER2_SEGSIZE		(1 << HAMMER2_FREEMAP_LEVEL0_RADIX)
#define HAMMER2_SEGRADIX	HAMMER2_FREEMAP_LEVEL0_RADIX

#define HAMMER2_PBUFRADIX	16	/* physical buf (1<<16) bytes */
#define HAMMER2_PBUFSIZE	65536
#define HAMMER2_LBUFRADIX	14	/* logical buf (1<<14) bytes */
#define HAMMER2_LBUFSIZE	16384

/*
 * Generally speaking we want to use 16K and 64K I/Os
 */
#define HAMMER2_MINIORADIX	HAMMER2_LBUFRADIX
#define HAMMER2_MINIOSIZE	HAMMER2_LBUFSIZE

#define HAMMER2_IND_BYTES_MIN	HAMMER2_LBUFSIZE
#define HAMMER2_IND_BYTES_MAX	HAMMER2_PBUFSIZE
#define HAMMER2_IND_COUNT_MIN	(HAMMER2_IND_BYTES_MIN / \
				 sizeof(hammer2_blockref_t))
#define HAMMER2_IND_COUNT_MAX	(HAMMER2_IND_BYTES_MAX / \
				 sizeof(hammer2_blockref_t))

/*
 * In HAMMER2, arrays of blockrefs are fully set-associative, meaning that
 * any element can occur at any index and holes can be anywhere.  As a
 * future optimization we will be able to flag that such arrays are sorted
 * and thus optimize lookups, but for now we don't.
 *
 * Inodes embed either 512 bytes of direct data or an array of 8 blockrefs,
 * resulting in highly efficient storage for files <= 512 bytes and for files
 * <= 512KB.  Up to 8 directory entries can be referenced from a directory
 * without requiring an indirect block.
 *
 * Indirect blocks are typically either 4KB (64 blockrefs / ~4MB represented),
 * or 64KB (1024 blockrefs / ~64MB represented).
 */
#define HAMMER2_SET_COUNT		8	/* direct entries */
#define HAMMER2_SET_RADIX		3
#define HAMMER2_EMBEDDED_BYTES		512	/* inode blockset/dd size */
#define HAMMER2_EMBEDDED_RADIX		9

#define HAMMER2_PBUFMASK	(HAMMER2_PBUFSIZE - 1)
#define HAMMER2_LBUFMASK	(HAMMER2_LBUFSIZE - 1)
#define HAMMER2_SEGMASK		(HAMMER2_SEGSIZE - 1)

#define HAMMER2_LBUFMASK64	((hammer2_off_t)HAMMER2_LBUFMASK)
#define HAMMER2_PBUFSIZE64	((hammer2_off_t)HAMMER2_PBUFSIZE)
#define HAMMER2_PBUFMASK64	((hammer2_off_t)HAMMER2_PBUFMASK)
#define HAMMER2_SEGSIZE64	((hammer2_off_t)HAMMER2_SEGSIZE)
#define HAMMER2_SEGMASK64	((hammer2_off_t)HAMMER2_SEGMASK)

#define HAMMER2_UUID_STRING	"5cbb9ad1-862d-11dc-a94d-01301bb8a9f5"

/*
 * A HAMMER2 filesystem is always sized in multiples of 8MB.
 *
 * A 4MB segment is reserved at the beginning of each 2GB zone.  This segment
 * contains the volume header (or backup volume header), the free block
 * table, and possibly other information in the future.
 *
 * 4MB = 64 x 64K blocks.  Each 4MB segment is broken down as follows:
 *
 *	+-----------------------+
 *      |	Volume Hdr	| block 0	volume header & alternates
 *	+-----------------------+		(first four zones only)
 *	|   FreeBlk Section A   | block 1-4
 *	+-----------------------+
 *	|   FreeBlk Section B   | block 5-8
 *	+-----------------------+
 *	|   FreeBlk Section C   | block 9-12
 *	+-----------------------+
 *	|   FreeBlk Section D   | block 13-16
 *	+-----------------------+
 *      |			| block 17...63
 *      |	reserved	|
 *      |			|
 *	+-----------------------+
 *
 * The first few 2GB zones contain volume headers and volume header backups.
 * After that the volume header block# is reserved for future use.  Similarly,
 * there are many blocks related to various Freemap levels which are not
 * used in every segment and those are also reserved for future use.
 *
 *			Freemap (see the FREEMAP document)
 *
 * The freemap utilizes blocks #1-16 in 8 sets of 4 blocks.  Each block in
 * a set represents a level of depth in the freemap topology.  Eight sets
 * exist to prevent live updates from disturbing the state of the freemap
 * were a crash/reboot to occur.  That is, a live update is not committed
 * until the update's flush reaches the volume root.  There are FOUR volume
 * roots representing the last four synchronization points, so the freemap
 * must be consistent no matter which volume root is chosen by the mount
 * code.
 *
 * Each freemap set is 4 x 64K blocks and represents the 2GB, 2TB, 2PB,
 * and 2EB indirect map.  The volume header itself has a set of 8 freemap
 * blockrefs representing another 3 bits, giving us a total 64 bits of
 * representable address space.
 *
 * The Level 0 64KB block represents 2GB of storage represented by
 * (64 x struct hammer2_bmap_data).  Each structure represents 2MB of storage
 * and has a 256 bit bitmap, using 2 bits to represent a 16KB chunk of
 * storage.  These 2 bits represent the following states:
 *
 *	00	Free
 *	01	(reserved) (Possibly partially allocated)
 *	10	Possibly free
 *	11	Allocated
 *
 * One important thing to note here is that the freemap resolution is 16KB,
 * but the minimum storage allocation size is 1KB.  The hammer2 vfs keeps
 * track of sub-allocations in memory, which means that on a unmount or reboot
 * the entire 16KB of a partially allocated block will be considered fully
 * allocated.  It is possible for fragmentation to build up over time, but
 * defragmentation is fairly easy to accomplish since all modifications
 * allocate a new block.
 *
 * The Second thing to note is that due to the way snapshots and inode
 * replication works, deleting a file cannot immediately free the related
 * space.  Furthermore, deletions often do not bother to traverse the
 * block subhierarchy being deleted.  And to go even further, whole
 * sub-directory trees can be deleted simply by deleting the directory inode
 * at the top.  So even though we have a symbol to represent a 'possibly free'
 * block (binary 10), only the bulk free scanning code can actually use it.
 * Normal 'rm's or other deletions do not.
 *
 * WARNING!  ZONE_SEG and VOLUME_ALIGN must be a multiple of 1<<LEVEL0_RADIX
 *	     (i.e. a multiple of 2MB).  VOLUME_ALIGN must be >= ZONE_SEG.
 *
 * In Summary:
 *
 * (1) Modifications to freemap blocks 'allocate' a new copy (aka use a block
 *     from the next set).  The new copy is reused until a flush occurs at
 *     which point the next modification will then rotate to the next set.
 *
 * (2) A total of 10 freemap sets is required.
 *
 *     - 8 sets - 2 sets per volume header backup x 4 volume header backups
 *     - 2 sets used as backing store for the bulk freemap scan.
 *     - The freemap recovery scan which runs on-mount just uses the inactive
 *	 set for whichever volume header was selected by the mount code.
 *
 */
#define HAMMER2_VOLUME_ALIGN		(8 * 1024 * 1024)
#define HAMMER2_VOLUME_ALIGN64		((hammer2_off_t)HAMMER2_VOLUME_ALIGN)
#define HAMMER2_VOLUME_ALIGNMASK	(HAMMER2_VOLUME_ALIGN - 1)
#define HAMMER2_VOLUME_ALIGNMASK64     ((hammer2_off_t)HAMMER2_VOLUME_ALIGNMASK)

#define HAMMER2_NEWFS_ALIGN		(HAMMER2_VOLUME_ALIGN)
#define HAMMER2_NEWFS_ALIGN64		((hammer2_off_t)HAMMER2_VOLUME_ALIGN)
#define HAMMER2_NEWFS_ALIGNMASK		(HAMMER2_VOLUME_ALIGN - 1)
#define HAMMER2_NEWFS_ALIGNMASK64	((hammer2_off_t)HAMMER2_NEWFS_ALIGNMASK)

#define HAMMER2_ZONE_BYTES64		(2LLU * 1024 * 1024 * 1024)
#define HAMMER2_ZONE_MASK64		(HAMMER2_ZONE_BYTES64 - 1)
#define HAMMER2_ZONE_SEG		(4 * 1024 * 1024)
#define HAMMER2_ZONE_SEG64		((hammer2_off_t)HAMMER2_ZONE_SEG)
#define HAMMER2_ZONE_BLOCKS_SEG		(HAMMER2_ZONE_SEG / HAMMER2_PBUFSIZE)

#define HAMMER2_ZONE_VOLHDR		0	/* volume header or backup */
#define HAMMER2_ZONE_FREEMAP_00		1	/* normal freemap rotation */
#define HAMMER2_ZONE_FREEMAP_01		5	/* normal freemap rotation */
#define HAMMER2_ZONE_FREEMAP_02		9	/* normal freemap rotation */
#define HAMMER2_ZONE_FREEMAP_03		13	/* normal freemap rotation */
#define HAMMER2_ZONE_FREEMAP_04		17	/* normal freemap rotation */
#define HAMMER2_ZONE_FREEMAP_05		21	/* normal freemap rotation */
#define HAMMER2_ZONE_FREEMAP_06		25	/* normal freemap rotation */
#define HAMMER2_ZONE_FREEMAP_07		29	/* normal freemap rotation */
#define HAMMER2_ZONE_FREEMAP_END	33	/* (non-inclusive) */

#define HAMMER2_ZONE_UNUSED33		33
#define HAMMER2_ZONE_UNUSED34		34
#define HAMMER2_ZONE_UNUSED35		35
#define HAMMER2_ZONE_UNUSED36		36
#define HAMMER2_ZONE_UNUSED37		37
#define HAMMER2_ZONE_UNUSED38		38
#define HAMMER2_ZONE_UNUSED39		39
#define HAMMER2_ZONE_UNUSED40		40
#define HAMMER2_ZONE_UNUSED41		41
#define HAMMER2_ZONE_UNUSED42		42
#define HAMMER2_ZONE_UNUSED43		43
#define HAMMER2_ZONE_UNUSED44		44
#define HAMMER2_ZONE_UNUSED45		45
#define HAMMER2_ZONE_UNUSED46		46
#define HAMMER2_ZONE_UNUSED47		47
#define HAMMER2_ZONE_UNUSED48		48
#define HAMMER2_ZONE_UNUSED49		49
#define HAMMER2_ZONE_UNUSED50		50
#define HAMMER2_ZONE_UNUSED51		51
#define HAMMER2_ZONE_UNUSED52		52
#define HAMMER2_ZONE_UNUSED53		53
#define HAMMER2_ZONE_UNUSED54		54
#define HAMMER2_ZONE_UNUSED55		55
#define HAMMER2_ZONE_UNUSED56		56
#define HAMMER2_ZONE_UNUSED57		57
#define HAMMER2_ZONE_UNUSED58		58
#define HAMMER2_ZONE_UNUSED59		59
#define HAMMER2_ZONE_UNUSED60		60
#define HAMMER2_ZONE_UNUSED61		61
#define HAMMER2_ZONE_UNUSED62		62
#define HAMMER2_ZONE_UNUSED63		63
#define HAMMER2_ZONE_END		64	/* non-inclusive */

#define HAMMER2_NFREEMAPS		8	/* FREEMAP_00 - FREEMAP_07 */

						/* relative to FREEMAP_x */
#define HAMMER2_ZONEFM_LEVEL1		0	/* 2GB leafmap */
#define HAMMER2_ZONEFM_LEVEL2		1	/* 2TB indmap */
#define HAMMER2_ZONEFM_LEVEL3		2	/* 2PB indmap */
#define HAMMER2_ZONEFM_LEVEL4		3	/* 2EB indmap */
/* LEVEL5 is a set of 8 blockrefs in the volume header 16EB */

/*
 * Freemap radix.  Note that the LEVEL 1 blockref points to a 64KB freemap
 * block containing 1024 x LEVEL0 hammer2_bmap_data structures.  LEVEL 0
 * represents one structure.
 */
#define HAMMER2_FREEMAP_LEVEL5_RADIX	64	/* 16EB (end) */
#define HAMMER2_FREEMAP_LEVEL4_RADIX	61	/* 2EB */
#define HAMMER2_FREEMAP_LEVEL3_RADIX	51	/* 2PB */
#define HAMMER2_FREEMAP_LEVEL2_RADIX	41	/* 2TB */
#define HAMMER2_FREEMAP_LEVEL1_RADIX	31	/* 2GB */
#define HAMMER2_FREEMAP_LEVEL0_RADIX	21	/* 2MB (entry in l-1 leaf) */

#define HAMMER2_FREEMAP_LEVELN_PSIZE	65536	/* physical bytes */

#define HAMMER2_FREEMAP_LEVEL4_SIZE	((hammer2_off_t)1 <<		\
					 HAMMER2_FREEMAP_LEVEL4_RADIX)
#define HAMMER2_FREEMAP_LEVEL3_SIZE	((hammer2_off_t)1 <<		\
					 HAMMER2_FREEMAP_LEVEL3_RADIX)
#define HAMMER2_FREEMAP_LEVEL2_SIZE	((hammer2_off_t)1 <<		\
					 HAMMER2_FREEMAP_LEVEL2_RADIX)
#define HAMMER2_FREEMAP_LEVEL1_SIZE	((hammer2_off_t)1 <<		\
					 HAMMER2_FREEMAP_LEVEL1_RADIX)
#define HAMMER2_FREEMAP_LEVEL0_SIZE	((hammer2_off_t)1 <<		\
					 HAMMER2_FREEMAP_LEVEL0_RADIX)

#define HAMMER2_FREEMAP_LEVEL4_MASK	(HAMMER2_FREEMAP_LEVEL4_SIZE - 1)
#define HAMMER2_FREEMAP_LEVEL3_MASK	(HAMMER2_FREEMAP_LEVEL3_SIZE - 1)
#define HAMMER2_FREEMAP_LEVEL2_MASK	(HAMMER2_FREEMAP_LEVEL2_SIZE - 1)
#define HAMMER2_FREEMAP_LEVEL1_MASK	(HAMMER2_FREEMAP_LEVEL1_SIZE - 1)
#define HAMMER2_FREEMAP_LEVEL0_MASK	(HAMMER2_FREEMAP_LEVEL0_SIZE - 1)

#define HAMMER2_FREEMAP_COUNT		(int)(HAMMER2_FREEMAP_LEVELN_PSIZE / \
					 sizeof(hammer2_bmap_data_t))
#define HAMMER2_FREEMAP_BLOCK_RADIX	14
#define HAMMER2_FREEMAP_BLOCK_SIZE	(1 << HAMMER2_FREEMAP_BLOCK_RADIX)
#define HAMMER2_FREEMAP_BLOCK_MASK	(HAMMER2_FREEMAP_BLOCK_SIZE - 1)

/*
 * bitmap[] structure.  2 bits per HAMMER2_FREEMAP_BLOCK_SIZE.  Each bitmap[]
 * element is 32 bits and thus represents 16 blocks (radix 4).
 */
#define HAMMER2_BMAP_INDEX_RADIX	4
#define HAMMER2_BMAP_INDEX_SIZE		(HAMMER2_FREEMAP_BLOCK_SIZE * 16)
#define HAMMER2_BMAP_INDEX_MASK		(HAMMER2_BMAP_INDEX_SIZE - 1)

/*
 * Two linear areas can be reserved after the initial 2MB segment in the base
 * zone (the one starting at offset 0).  These areas are NOT managed by the
 * block allocator and do not fall under HAMMER2 crc checking rules based
 * at the volume header (but can be self-CRCd internally, depending).
 */
#define HAMMER2_BOOT_MIN_BYTES		HAMMER2_VOLUME_ALIGN
#define HAMMER2_BOOT_NOM_BYTES		(64*1024*1024)
#define HAMMER2_BOOT_MAX_BYTES		(256*1024*1024)

#define HAMMER2_REDO_MIN_BYTES		HAMMER2_VOLUME_ALIGN
#define HAMMER2_REDO_NOM_BYTES		(256*1024*1024)
#define HAMMER2_REDO_MAX_BYTES		(1024*1024*1024)

/*
 * Most HAMMER2 types are implemented as unsigned 64-bit integers.
 * Transaction ids are monotonic.
 *
 * We utilize 32-bit iSCSI CRCs.
 */
typedef uint64_t hammer2_tid_t;
typedef uint64_t hammer2_off_t;
typedef uint64_t hammer2_key_t;
typedef uint32_t hammer2_crc32_t;

/*
 * Miscellanious ranges (all are unsigned).
 */
#define HAMMER2_TID_MIN		1ULL
#define HAMMER2_TID_MAX		0xFFFFFFFFFFFFFFFFULL
#define HAMMER2_KEY_MIN		0ULL
#define HAMMER2_KEY_MAX		0xFFFFFFFFFFFFFFFFULL
#define HAMMER2_OFFSET_MIN	0ULL
#define HAMMER2_OFFSET_MAX	0xFFFFFFFFFFFFFFFFULL

/*
 * HAMMER2 data offset special cases and masking.
 *
 * All HAMMER2 data offsets have to be broken down into a 64K buffer base
 * offset (HAMMER2_OFF_MASK_HI) and a 64K buffer index (HAMMER2_OFF_MASK_LO).
 *
 * Indexes into physical buffers are always 64-byte aligned.  The low 6 bits
 * of the data offset field specifies how large the data chunk being pointed
 * to as a power of 2.  The theoretical minimum radix is thus 6 (The space
 * needed in the low bits of the data offset field).  However, the practical
 * minimum allocation chunk size is 1KB (a radix of 10), so HAMMER2 sets
 * HAMMER2_RADIX_MIN to 10.  The maximum radix is currently 16 (64KB), but
 * we fully intend to support larger extents in the future.
 */
#define HAMMER2_OFF_BAD		((hammer2_off_t)-1)
#define HAMMER2_OFF_MASK	0xFFFFFFFFFFFFFFC0ULL
#define HAMMER2_OFF_MASK_LO	(HAMMER2_OFF_MASK & HAMMER2_PBUFMASK64)
#define HAMMER2_OFF_MASK_HI	(~HAMMER2_PBUFMASK64)
#define HAMMER2_OFF_MASK_RADIX	0x000000000000003FULL
#define HAMMER2_MAX_COPIES	6

/*
 * HAMMER2 directory support and pre-defined keys
 */
#define HAMMER2_DIRHASH_VISIBLE	0x8000000000000000ULL
#define HAMMER2_DIRHASH_USERMSK	0x7FFFFFFFFFFFFFFFULL
#define HAMMER2_DIRHASH_LOMASK	0x0000000000007FFFULL
#define HAMMER2_DIRHASH_HIMASK	0xFFFFFFFFFFFF0000ULL
#define HAMMER2_DIRHASH_FORCED	0x0000000000008000ULL	/* bit forced on */

#define HAMMER2_SROOT_KEY	0x0000000000000000ULL	/* volume to sroot */

/************************************************************************
 *				DMSG SUPPORT				*
 ************************************************************************
 * LNK_VOLCONF
 *
 * All HAMMER2 directories directly under the super-root on your local
 * media can be mounted separately, even if they share the same physical
 * device.
 *
 * When you do a HAMMER2 mount you are effectively tying into a HAMMER2
 * cluster via local media.  The local media does not have to participate
 * in the cluster, other than to provide the hammer2_volconf[] array and
 * root inode for the mount.
 *
 * This is important: The mount device path you specify serves to bootstrap
 * your entry into the cluster, but your mount will make active connections
 * to ALL copy elements in the hammer2_volconf[] array which match the
 * PFSID of the directory in the super-root that you specified.  The local
 * media path does not have to be mentioned in this array but becomes part
 * of the cluster based on its type and access rights.  ALL ELEMENTS ARE
 * TREATED ACCORDING TO TYPE NO MATTER WHICH ONE YOU MOUNT FROM.
 *
 * The actual cluster may be far larger than the elements you list in the
 * hammer2_volconf[] array.  You list only the elements you wish to
 * directly connect to and you are able to access the rest of the cluster
 * indirectly through those connections.
 *
 * WARNING!  This structure must be exactly 128 bytes long for its config
 *	     array to fit in the volume header.
 */
struct hammer2_volconf {
	uint8_t	copyid;		/* 00	 copyid 0-255 (must match slot) */
	uint8_t inprog;		/* 01	 operation in progress, or 0 */
	uint8_t chain_to;	/* 02	 operation chaining to, or 0 */
	uint8_t chain_from;	/* 03	 operation chaining from, or 0 */
	uint16_t flags;		/* 04-05 flags field */
	uint8_t error;		/* 06	 last operational error */
	uint8_t priority;	/* 07	 priority and round-robin flag */
	uint8_t remote_pfs_type;/* 08	 probed direct remote PFS type */
	uint8_t reserved08[23];	/* 09-1F */
	uuid_t	pfs_clid;	/* 20-2F copy target must match this uuid */
	uint8_t label[16];	/* 30-3F import/export label */
	uint8_t path[64];	/* 40-7F target specification string or key */
};

typedef struct hammer2_volconf hammer2_volconf_t;

#define DMSG_VOLF_ENABLED	0x0001
#define DMSG_VOLF_INPROG	0x0002
#define DMSG_VOLF_CONN_RR	0x80	/* round-robin at same priority */
#define DMSG_VOLF_CONN_EF	0x40	/* media errors flagged */
#define DMSG_VOLF_CONN_PRI	0x0F	/* select priority 0-15 (15=best) */

struct dmsg_lnk_hammer2_volconf {
	dmsg_hdr_t		head;
	hammer2_volconf_t	copy;	/* copy spec */
	int32_t			index;
	int32_t			unused01;
	uuid_t			mediaid;
	int64_t			reserved02[32];
};

typedef struct dmsg_lnk_hammer2_volconf dmsg_lnk_hammer2_volconf_t;

#define DMSG_LNK_HAMMER2_VOLCONF DMSG_LNK(DMSG_LNK_CMD_HAMMER2_VOLCONF, \
					  dmsg_lnk_hammer2_volconf)

#define H2_LNK_VOLCONF(msg)	((dmsg_lnk_hammer2_volconf_t *)(msg)->any.buf)

/*
 * The media block reference structure.  This forms the core of the HAMMER2
 * media topology recursion.  This 64-byte data structure is embedded in the
 * volume header, in inodes (which are also directory entries), and in
 * indirect blocks.
 *
 * A blockref references a single media item, which typically can be a
 * directory entry (aka inode), indirect block, or data block.
 *
 * The primary feature a blockref represents is the ability to validate
 * the entire tree underneath it via its check code.  Any modification to
 * anything propagates up the blockref tree all the way to the root, replacing
 * the related blocks.  Propagations can shortcut to the volume root to
 * implement the 'fast syncing' feature but this only delays the eventual
 * propagation.
 *
 * The check code can be a simple 32-bit iscsi code, a 64-bit crc,
 * or as complex as a 192 bit cryptographic hash.  192 bits is the maximum
 * supported check code size, which is not sufficient for unverified dedup
 * UNLESS one doesn't mind once-in-a-blue-moon data corruption (such as when
 * farming web data).  HAMMER2 has an unverified dedup feature for just this
 * purpose.
 *
 * --
 *
 * NOTE: The range of keys represented by the blockref is (key) to
 *	 ((key) + (1LL << keybits) - 1).  HAMMER2 usually populates
 *	 blocks bottom-up, inserting a new root when radix expansion
 *	 is required.
 *
 * --
 *				FUTURE BLOCKREF EXPANSION
 *
 * In order to implement a 256-bit content addressable index we want to
 * have a 256-bit key which essentially represents the cryptographic hash.
 * (so, 64-bit key + 192-bit crypto-hash or 256-bit key-is-the-hash +
 * 32-bit consistency check for indirect block layers).
 *
 * THIS IS POSSIBLE in a 64-byte blockref structure.  Of course, any number
 * of bits can be represented by sizing the blockref.  For the purposes of
 * HAMMER2 though my limit is 256 bits.  Not only that, but it will be an
 * optimal construction because H2 already uses a variably-sized radix to
 * pack the blockrefs at each level.  A 256-bit mechanic would allow us
 * to implement a content-addressable index.
 */
struct hammer2_blockref {		/* MUST BE EXACTLY 64 BYTES */
	uint8_t		type;		/* type of underlying item */
	uint8_t		methods;	/* check method & compression method */
	uint8_t		copyid;		/* specify which copy this is */
	uint8_t		keybits;	/* #of keybits masked off 0=leaf */
	uint8_t		vradix;		/* virtual data/meta-data size */
	uint8_t		flags;		/* blockref flags */
	uint8_t		reserved06;
	uint8_t		reserved07;
	hammer2_key_t	key;		/* key specification */
	hammer2_tid_t	mirror_tid;	/* media flush topology & freemap */
	hammer2_tid_t	modify_tid;	/* cluster level change / flush */
	hammer2_off_t	data_off;	/* low 6 bits is phys size (radix)*/
	union {				/* check info */
		char	buf[24];
		struct {
			uint32_t value;
			uint32_t unused[5];
		} iscsi32;
		struct {
			uint64_t value;
			uint64_t unused[2];
		} crc64;
		struct {
			char data[24];
		} sha192;

		/*
		 * Freemap hints are embedded in addition to the icrc32.
		 *
		 * bigmask - Radixes available for allocation (0-31).
		 *	     Heuristical (may be permissive but not
		 *	     restrictive).  Typically only radix values
		 *	     10-16 are used (i.e. (1<<10) through (1<<16)).
		 *
		 * avail   - Total available space remaining, in bytes
		 */
		struct {
			uint32_t icrc32;
			uint32_t bigmask;	/* available radixes */
			uint64_t avail;		/* total available bytes */
			uint64_t unused;	/* unused must be 0 */
		} freemap;
	} check;
};

typedef struct hammer2_blockref hammer2_blockref_t;

#define HAMMER2_BLOCKREF_BYTES		64	/* blockref struct in bytes */

/*
 * On-media and off-media blockref types.
 *
 * types >= 128 are pseudo values that should never be present on-media.
 */
#define HAMMER2_BREF_TYPE_EMPTY		0
#define HAMMER2_BREF_TYPE_INODE		1
#define HAMMER2_BREF_TYPE_INDIRECT	2
#define HAMMER2_BREF_TYPE_DATA		3
#define HAMMER2_BREF_TYPE_UNUSED04	4
#define HAMMER2_BREF_TYPE_FREEMAP_NODE	5
#define HAMMER2_BREF_TYPE_FREEMAP_LEAF	6
#define HAMMER2_BREF_TYPE_FREEMAP	254	/* pseudo-type */
#define HAMMER2_BREF_TYPE_VOLUME	255	/* pseudo-type */

#define HAMMER2_BREF_FLAG_PFSROOT	0x01	/* see also related opflag */
#define HAMMER2_BREF_FLAG_ZERO		0x02

/*
 * Encode/decode check mode and compression mode for
 * bref.methods.  The compression level is not encoded in
 * bref.methods.
 */
#define HAMMER2_ENC_CHECK(n)		(((n) & 15) << 4)
#define HAMMER2_DEC_CHECK(n)		(((n) >> 4) & 15)
#define HAMMER2_ENC_COMP(n)		((n) & 15)
#define HAMMER2_DEC_COMP(n)		((n) & 15)

#define HAMMER2_CHECK_NONE		0
#define HAMMER2_CHECK_DISABLED		1
#define HAMMER2_CHECK_ISCSI32		2
#define HAMMER2_CHECK_CRC64		3
#define HAMMER2_CHECK_SHA192		4
#define HAMMER2_CHECK_FREEMAP		5

/* user-specifiable check modes only */
#define HAMMER2_CHECK_STRINGS		{ "none", "disabled", "crc32", \
					  "crc64", "sha192" }
#define HAMMER2_CHECK_STRINGS_COUNT	5

/*
 * Encode/decode check or compression algorithm request in
 * ipdata->check_algo and ipdata->comp_algo.
 */
#define HAMMER2_ENC_ALGO(n)		(n)
#define HAMMER2_DEC_ALGO(n)		((n) & 15)
#define HAMMER2_ENC_LEVEL(n)		((n) << 4)
#define HAMMER2_DEC_LEVEL(n)		(((n) >> 4) & 15)

#define HAMMER2_COMP_NONE		0
#define HAMMER2_COMP_AUTOZERO		1
#define HAMMER2_COMP_LZ4		2
#define HAMMER2_COMP_ZLIB		3

#define HAMMER2_COMP_NEWFS_DEFAULT	HAMMER2_COMP_LZ4
#define HAMMER2_COMP_STRINGS		{ "none", "autozero", "lz4", "zlib" }
#define HAMMER2_COMP_STRINGS_COUNT	4


/*
 * HAMMER2 block references are collected into sets of 8 blockrefs.  These
 * sets are fully associative, meaning the elements making up a set are
 * not sorted in any way and may contain duplicate entries, holes, or
 * entries which shortcut multiple levels of indirection.  Sets are used
 * in various ways:
 *
 * (1) When redundancy is desired a set may contain several duplicate
 *     entries pointing to different copies of the same data.  Up to 8 copies
 *     are supported but the set structure becomes a bit inefficient once
 *     you go over 4.
 *
 * (2) The blockrefs in a set can shortcut multiple levels of indirections
 *     within the bounds imposed by the parent of set.
 *
 * When a set fills up another level of indirection is inserted, moving
 * some or all of the set's contents into indirect blocks placed under the
 * set.  This is a top-down approach in that indirect blocks are not created
 * until the set actually becomes full (that is, the entries in the set can
 * shortcut the indirect blocks when the set is not full).  Depending on how
 * things are filled multiple indirect blocks will eventually be created.
 *
 * Indirect blocks are typically 4KB (64 entres) or 64KB (1024 entries) and
 * are also treated as fully set-associative.
 */
struct hammer2_blockset {
	hammer2_blockref_t	blockref[HAMMER2_SET_COUNT];
};

typedef struct hammer2_blockset hammer2_blockset_t;

/*
 * Catch programmer snafus
 */
#if (1 << HAMMER2_SET_RADIX) != HAMMER2_SET_COUNT
#error "hammer2 direct radix is incorrect"
#endif
#if (1 << HAMMER2_PBUFRADIX) != HAMMER2_PBUFSIZE
#error "HAMMER2_PBUFRADIX and HAMMER2_PBUFSIZE are inconsistent"
#endif
#if (1 << HAMMER2_RADIX_MIN) != HAMMER2_ALLOC_MIN
#error "HAMMER2_RADIX_MIN and HAMMER2_ALLOC_MIN are inconsistent"
#endif

/*
 * hammer2_bmap_data - A freemap entry in the LEVEL1 block.
 *
 * Each 64-byte entry contains the bitmap and meta-data required to manage
 * a LEVEL0 (2MB) block of storage.  The storage is managed in 128 x 16KB
 * chunks.  Smaller allocation granularity is supported via a linear iterator
 * and/or must otherwise be tracked in ram.
 *
 * (data structure must be 64 bytes exactly)
 *
 * linear  - A BYTE linear allocation offset used for sub-16KB allocations
 *	     only.  May contain values between 0 and 2MB.  Must be ignored
 *	     if 16KB-aligned (i.e. force bitmap scan), otherwise may be
 *	     used to sub-allocate within the 16KB block (which is already
 *	     marked as allocated in the bitmap).
 *
 *	     Sub-allocations need only be 1KB-aligned and do not have to be
 *	     size-aligned, and 16KB or larger allocations do not update this
 *	     field, resulting in pretty good packing.
 *
 *	     Please note that file data granularity may be limited by
 *	     other issues such as buffer cache direct-mapping and the
 *	     desire to support sector sizes up to 16KB (so H2 only issues
 *	     I/O's in multiples of 16KB anyway).
 *
 * class   - Clustering class.  Cleared to 0 only if the entire leaf becomes
 *	     free.  Used to cluster device buffers so all elements must have
 *	     the same device block size, but may mix logical sizes.
 *
 *	     Typically integrated with the blockref type in the upper 8 bits
 *	     to localize inodes and indrect blocks, improving bulk free scans
 *	     and directory scans.
 *
 * bitmap  - Two bits per 16KB allocation block arranged in arrays of
 *	     32-bit elements, 128x2 bits representing ~2MB worth of media
 *	     storage.  Bit patterns are as follows:
 *
 *	     00	Unallocated
 *	     01 (reserved)
 *	     10 Possibly free
 *           11 Allocated
 */
struct hammer2_bmap_data {
	int32_t linear;		/* 00 linear sub-granular allocation offset */
	uint16_t class;		/* 04-05 clustering class ((type<<8)|radix) */
	uint8_t reserved06;	/* 06 */
	uint8_t reserved07;	/* 07 */
	uint32_t reserved08;	/* 08 */
	uint32_t reserved0C;	/* 0C */
	uint32_t reserved10;	/* 10 */
	uint32_t reserved14;	/* 14 */
	uint32_t reserved18;	/* 18 */
	uint32_t avail;		/* 1C */
	uint32_t bitmap[8];	/* 20-3F 256 bits manages 2MB/16KB/2-bits */
};

typedef struct hammer2_bmap_data hammer2_bmap_data_t;

/*
 * In HAMMER2 inodes ARE directory entries, with a special exception for
 * hardlinks.  The inode number is stored in the inode rather than being
 * based on the location of the inode (since the location moves every time
 * the inode or anything underneath the inode is modified).
 *
 * The inode is 1024 bytes, made up of 256 bytes of meta-data, 256 bytes
 * for the filename, and 512 bytes worth of direct file data OR an embedded
 * blockset.
 *
 * Directories represent one inode per blockref.  Inodes are not laid out
 * as a file but instead are represented by the related blockrefs.  The
 * blockrefs, in turn, are indexed by the 64-bit directory hash key.  Remember
 * that blocksets are fully associative, so a certain degree efficiency is
 * achieved just from that.
 *
 * Up to 512 bytes of direct data can be embedded in an inode, and since
 * inodes are essentially directory entries this also means that small data
 * files end up simply being laid out linearly in the directory, resulting
 * in fewer seeks and highly optimal access.
 *
 * The compression mode can be changed at any time in the inode and is
 * recorded on a blockref-by-blockref basis.
 *
 * Hardlinks are supported via the inode map.  Essentially the way a hardlink
 * works is that all individual directory entries representing the same file
 * are special cased and specify the same inode number.  The actual file
 * is placed in the nearest parent directory that is parent to all instances
 * of the hardlink.  If all hardlinks to a file are in the same directory
 * the actual file will also be placed in that directory.  This file uses
 * the inode number as the directory entry key and is invisible to normal
 * directory scans.  Real directory entry keys are differentiated from the
 * inode number key via bit 63.  Access to the hardlink silently looks up
 * the real file and forwards all operations to that file.  Removal of the
 * last hardlink also removes the real file.
 *
 * (attr_tid) is only updated when the inode's specific attributes or regular
 * file size has changed, and affects path lookups and stat.  (attr_tid)
 * represents a special cache coherency lock under the inode.  The inode
 * blockref's modify_tid will always cover it.
 *
 * (dirent_tid) is only updated when an entry under a directory inode has
 * been created, deleted, renamed, or had its attributes change, and affects
 * directory lookups and scans.  (dirent_tid) represents another special cache
 * coherency lock under the inode.  The inode blockref's modify_tid will
 * always cover it.
 */
#define HAMMER2_INODE_BYTES		1024	/* (asserted by code) */
#define HAMMER2_INODE_MAXNAME		256	/* maximum name in bytes */
#define HAMMER2_INODE_VERSION_ONE	1

#define HAMMER2_INODE_HIDDENDIR		16	/* special inode */
#define HAMMER2_INODE_START		1024	/* dynamically allocated */

struct hammer2_inode_data {
	uint16_t	version;	/* 0000 inode data version */
	uint8_t		reserved02;	/* 0002 */
	uint8_t		pfs_subtype;	/* 0003 pfs sub-type */

	/*
	 * core inode attributes, inode type, misc flags
	 */
	uint32_t	uflags;		/* 0004 chflags */
	uint32_t	rmajor;		/* 0008 available for device nodes */
	uint32_t	rminor;		/* 000C available for device nodes */
	uint64_t	ctime;		/* 0010 inode change time */
	uint64_t	mtime;		/* 0018 modified time */
	uint64_t	atime;		/* 0020 access time (unsupported) */
	uint64_t	btime;		/* 0028 birth time */
	uuid_t		uid;		/* 0030 uid / degenerate unix uid */
	uuid_t		gid;		/* 0040 gid / degenerate unix gid */

	uint8_t		type;		/* 0050 object type */
	uint8_t		op_flags;	/* 0051 operational flags */
	uint16_t	cap_flags;	/* 0052 capability flags */
	uint32_t	mode;		/* 0054 unix modes (typ low 16 bits) */

	/*
	 * inode size, identification, localized recursive configuration
	 * for compression and backup copies.
	 */
	hammer2_tid_t	inum;		/* 0058 inode number */
	hammer2_off_t	size;		/* 0060 size of file */
	uint64_t	nlinks;		/* 0068 hard links (typ only dirs) */
	hammer2_tid_t	iparent;	/* 0070 parent inum (recovery only) */
	hammer2_key_t	name_key;	/* 0078 full filename key */
	uint16_t	name_len;	/* 0080 filename length */
	uint8_t		ncopies;	/* 0082 ncopies to local media */
	uint8_t		comp_algo;	/* 0083 compression request & algo */

	/*
	 * These fields are currently only applicable to PFSROOTs.
	 *
	 * NOTE: We can't use {volume_data->fsid, pfs_clid} to uniquely
	 *	 identify an instance of a PFS in the cluster because
	 *	 a mount may contain more than one copy of the PFS as
	 *	 a separate node.  {pfs_clid, pfs_fsid} must be used for
	 *	 registration in the cluster.
	 */
	uint8_t		target_type;	/* 0084 hardlink target type */
	uint8_t		check_algo;	/* 0085 check code request & algo */
	uint8_t		pfs_nmasters;	/* 0086 (if PFSROOT) if multi-master */
	uint8_t		pfs_type;	/* 0087 (if PFSROOT) node type */
	uint64_t	pfs_inum;	/* 0088 (if PFSROOT) inum allocator */
	uuid_t		pfs_clid;	/* 0090 (if PFSROOT) cluster uuid */
	uuid_t		pfs_fsid;	/* 00A0 (if PFSROOT) unique uuid */

	/*
	 * Quotas and aggregate sub-tree inode and data counters.  Note that
	 * quotas are not replicated downward, they are explicitly set by
	 * the sysop and in-memory structures keep track of inheritence.
	 */
	hammer2_key_t	data_quota;	/* 00B0 subtree quota in bytes */
	hammer2_key_t	data_count;	/* 00B8 subtree byte count */
	hammer2_key_t	inode_quota;	/* 00C0 subtree quota inode count */
	hammer2_key_t	inode_count;	/* 00C8 subtree inode count */
	hammer2_tid_t	attr_tid;	/* 00D0 attributes changed */
	hammer2_tid_t	dirent_tid;	/* 00D8 directory/attr changed */

	/*
	 * Tracks (possibly degenerate) free areas covering all sub-tree
	 * allocations under inode, not counting the inode itself.
	 * 0/0 indicates empty entry.  fully set-associative.
	 *
	 * (not yet implemented)
	 */
	uint64_t	decrypt_check;	/* 00E0 decryption validator */
	hammer2_off_t	reservedE0[3];	/* 00E8/F0/F8 */

	unsigned char	filename[HAMMER2_INODE_MAXNAME];
					/* 0100-01FF (256 char, unterminated) */
	union {				/* 0200-03FF (64x8 = 512 bytes) */
		struct hammer2_blockset blockset;
		char data[HAMMER2_EMBEDDED_BYTES];
	} u;
};

typedef struct hammer2_inode_data hammer2_inode_data_t;

#define HAMMER2_OPFLAG_DIRECTDATA	0x01
#define HAMMER2_OPFLAG_PFSROOT		0x02	/* (see also bref flag) */
#define HAMMER2_OPFLAG_COPYIDS		0x04	/* copyids override parent */

#define HAMMER2_OBJTYPE_UNKNOWN		0
#define HAMMER2_OBJTYPE_DIRECTORY	1
#define HAMMER2_OBJTYPE_REGFILE		2
#define HAMMER2_OBJTYPE_FIFO		4
#define HAMMER2_OBJTYPE_CDEV		5
#define HAMMER2_OBJTYPE_BDEV		6
#define HAMMER2_OBJTYPE_SOFTLINK	7
#define HAMMER2_OBJTYPE_HARDLINK	8	/* dummy entry for hardlink */
#define HAMMER2_OBJTYPE_SOCKET		9
#define HAMMER2_OBJTYPE_WHITEOUT	10

#define HAMMER2_COPYID_NONE		0
#define HAMMER2_COPYID_LOCAL		((uint8_t)-1)

#define HAMMER2_COPYID_COUNT		256

/*
 * PFS types identify the role of a PFS within a cluster.  The PFS types
 * is stored on media and in LNK_SPAN messages and used in other places.
 *
 * The low 4 bits specify the current active type while the high 4 bits
 * specify the transition target if the PFS is being upgraded or downgraded,
 * If the upper 4 bits are not zero it may effect how a PFS is used during
 * the transition.
 *
 * Generally speaking, downgrading a MASTER to a SLAVE cannot complete until
 * at least all MASTERs have updated their pfs_nmasters field.  And upgrading
 * a SLAVE to a MASTER cannot complete until the new prospective master has
 * been fully synchronized (though theoretically full synchronization is
 * not required if a (new) quorum of other masters are fully synchronized).
 *
 * It generally does not matter which PFS element you actually mount, you
 * are mounting 'the cluster'.  So, for example, a network mount will mount
 * a DUMMY PFS type on a memory filesystem.  However, there are two exceptions.
 * In order to gain the benefits of a SOFT_MASTER or SOFT_SLAVE, those PFSs
 * must be directly mounted.
 */
#define HAMMER2_PFSTYPE_NONE		0x00
#define HAMMER2_PFSTYPE_CACHE		0x01
#define HAMMER2_PFSTYPE_UNUSED02	0x02
#define HAMMER2_PFSTYPE_SLAVE		0x03
#define HAMMER2_PFSTYPE_SOFT_SLAVE	0x04
#define HAMMER2_PFSTYPE_SOFT_MASTER	0x05
#define HAMMER2_PFSTYPE_MASTER		0x06
#define HAMMER2_PFSTYPE_UNUSED07	0x07
#define HAMMER2_PFSTYPE_SUPROOT		0x08
#define HAMMER2_PFSTYPE_DUMMY		0x09
#define HAMMER2_PFSTYPE_MAX		16

#define HAMMER2_PFSTRAN_NONE		0x00	/* no transition in progress */
#define HAMMER2_PFSTRAN_CACHE		0x10
#define HAMMER2_PFSTRAN_UNMUSED20	0x20
#define HAMMER2_PFSTRAN_SLAVE		0x30
#define HAMMER2_PFSTRAN_SOFT_SLAVE	0x40
#define HAMMER2_PFSTRAN_SOFT_MASTER	0x50
#define HAMMER2_PFSTRAN_MASTER		0x60
#define HAMMER2_PFSTRAN_UNUSED70	0x70
#define HAMMER2_PFSTRAN_SUPROOT		0x80
#define HAMMER2_PFSTRAN_DUMMY		0x90

#define HAMMER2_PFS_DEC(n)		((n) & 0x0F)
#define HAMMER2_PFS_DEC_TRANSITION(n)	(((n) >> 4) & 0x0F)
#define HAMMER2_PFS_ENC_TRANSITION(n)	(((n) & 0x0F) << 4)

#define HAMMER2_PFSSUBTYPE_NONE		0
#define HAMMER2_PFSSUBTYPE_SNAPSHOT	1	/* manual/managed snapshot */
#define HAMMER2_PFSSUBTYPE_AUTOSNAP	2	/* automatic snapshot */

/*
 * PFS mode of operation is a bitmask.  This is typically not stored
 * on-media, but defined here because the field may be used in dmsgs.
 */
#define HAMMER2_PFSMODE_QUORUM		0x01
#define HAMMER2_PFSMODE_RW		0x02

/*
 *				Allocation Table
 *
 */


/*
 * Flags (8 bits) - blockref, for freemap only
 *
 * Note that the minimum chunk size is 1KB so we could theoretically have
 * 10 bits here, but we might have some future extension that allows a
 * chunk size down to 256 bytes and if so we will need bits 8 and 9.
 */
#define HAMMER2_AVF_SELMASK		0x03	/* select group */
#define HAMMER2_AVF_ALL_ALLOC		0x04	/* indicate all allocated */
#define HAMMER2_AVF_ALL_FREE		0x08	/* indicate all free */
#define HAMMER2_AVF_RESERVED10		0x10
#define HAMMER2_AVF_RESERVED20		0x20
#define HAMMER2_AVF_RESERVED40		0x40
#define HAMMER2_AVF_RESERVED80		0x80
#define HAMMER2_AVF_AVMASK32		((uint32_t)0xFFFFFF00LU)
#define HAMMER2_AVF_AVMASK64		((uint64_t)0xFFFFFFFFFFFFFF00LLU)

#define HAMMER2_AV_SELECT_A		0x00
#define HAMMER2_AV_SELECT_B		0x01
#define HAMMER2_AV_SELECT_C		0x02
#define HAMMER2_AV_SELECT_D		0x03

/*
 * The volume header eats a 64K block.  There is currently an issue where
 * we want to try to fit all nominal filesystem updates in a 512-byte section
 * but it may be a lost cause due to the need for a blockset.
 *
 * All information is stored in host byte order.  The volume header's magic
 * number may be checked to determine the byte order.  If you wish to mount
 * between machines w/ different endian modes you'll need filesystem code
 * which acts on the media data consistently (either all one way or all the
 * other).  Our code currently does not do that.
 *
 * A read-write mount may have to recover missing allocations by doing an
 * incremental mirror scan looking for modifications made after alloc_tid.
 * If alloc_tid == last_tid then no recovery operation is needed.  Recovery
 * operations are usually very, very fast.
 *
 * Read-only mounts do not need to do any recovery, access to the filesystem
 * topology is always consistent after a crash (is always consistent, period).
 * However, there may be shortcutted blockref updates present from deep in
 * the tree which are stored in the volumeh eader and must be tracked on
 * the fly.
 *
 * NOTE: The copyinfo[] array contains the configuration for both the
 *	 cluster connections and any local media copies.  The volume
 *	 header will be replicated for each local media copy.
 *
 *	 The mount command may specify multiple medias or just one and
 *	 allow HAMMER2 to pick up the others when it checks the copyinfo[]
 *	 array on mount.
 *
 * NOTE: root_blockref points to the super-root directory, not the root
 *	 directory.  The root directory will be a subdirectory under the
 *	 super-root.
 *
 *	 The super-root directory contains all root directories and all
 *	 snapshots (readonly or writable).  It is possible to do a
 *	 null-mount of the super-root using special path constructions
 *	 relative to your mounted root.
 *
 * NOTE: HAMMER2 allows any subdirectory tree to be managed as if it were
 *	 a PFS, including mirroring and storage quota operations, and this is
 *	 prefered over creating discrete PFSs in the super-root.  Instead
 *	 the super-root is most typically used to create writable snapshots,
 *	 alternative roots, and so forth.  The super-root is also used by
 *	 the automatic snapshotting mechanism.
 */
#define HAMMER2_VOLUME_ID_HBO	0x48414d3205172011LLU
#define HAMMER2_VOLUME_ID_ABO	0x11201705324d4148LLU

struct hammer2_volume_data {
	/*
	 * sector #0 - 512 bytes
	 */
	uint64_t	magic;			/* 0000 Signature */
	hammer2_off_t	boot_beg;		/* 0008 Boot area (future) */
	hammer2_off_t	boot_end;		/* 0010 (size = end - beg) */
	hammer2_off_t	aux_beg;		/* 0018 Aux area (future) */
	hammer2_off_t	aux_end;		/* 0020 (size = end - beg) */
	hammer2_off_t	volu_size;		/* 0028 Volume size, bytes */

	uint32_t	version;		/* 0030 */
	uint32_t	flags;			/* 0034 */
	uint8_t		copyid;			/* 0038 copyid of phys vol */
	uint8_t		freemap_version;	/* 0039 freemap algorithm */
	uint8_t		peer_type;		/* 003A HAMMER2_PEER_xxx */
	uint8_t		reserved003B;		/* 003B */
	uint32_t	reserved003C;		/* 003C */

	uuid_t		fsid;			/* 0040 */
	uuid_t		fstype;			/* 0050 */

	/*
	 * allocator_size is precalculated at newfs time and does not include
	 * reserved blocks, boot, or redo areas.
	 *
	 * Initial non-reserved-area allocations do not use the freemap
	 * but instead adjust alloc_iterator.  Dynamic allocations take
	 * over starting at (allocator_beg).  This makes newfs_hammer2's
	 * job a lot easier and can also serve as a testing jig.
	 */
	hammer2_off_t	allocator_size;		/* 0060 Total data space */
	hammer2_off_t   allocator_free;		/* 0068	Free space */
	hammer2_off_t	allocator_beg;		/* 0070 Initial allocations */

	/*
	 * mirror_tid reflects the highest committed change for this
	 * block device regardless of whether it is to the super-root
	 * or to a PFS or whatever.
	 *
	 * freemap_tid reflects the highest committed freemap change for
	 * this block device.
	 */
	hammer2_tid_t	mirror_tid;		/* 0078 committed tid (vol) */
	hammer2_tid_t	reserved0080;		/* 0080 */
	hammer2_tid_t	reserved0088;		/* 0088 */
	hammer2_tid_t	freemap_tid;		/* 0090 committed tid (fmap) */
	hammer2_tid_t	bulkfree_tid;		/* 0098 bulkfree incremental */
	hammer2_tid_t	reserved00A0[5];	/* 00A0-00C7 */

	/*
	 * Copyids are allocated dynamically from the copyexists bitmap.
	 * An id from the active copies set (up to 8, see copyinfo later on)
	 * may still exist after the copy set has been removed from the
	 * volume header and its bit will remain active in the bitmap and
	 * cannot be reused until it is 100% removed from the hierarchy.
	 */
	uint32_t	copyexists[8];		/* 00C8-00E7 copy exists bmap */
	char		reserved0140[248];	/* 00E8-01DF */

	/*
	 * 32 bit CRC array at the end of the first 512 byte sector.
	 *
	 * icrc_sects[7] - First 512-4 bytes of volume header (including all
	 *		   the other icrc's except this one).
	 *
	 * icrc_sects[6] - Sector 1 (512 bytes) of volume header, which is
	 *		   the blockset for the root.
	 *
	 * icrc_sects[5] - Sector 2
	 * icrc_sects[4] - Sector 3
	 * icrc_sects[3] - Sector 4 (the freemap blockset)
	 */
	hammer2_crc32_t	icrc_sects[8];		/* 01E0-01FF */

	/*
	 * sector #1 - 512 bytes
	 *
	 * The entire sector is used by a blockset.
	 */
	hammer2_blockset_t sroot_blockset;	/* 0200-03FF Superroot dir */

	/*
	 * sector #2-7
	 */
	char	sector2[512];			/* 0400-05FF reserved */
	char	sector3[512];			/* 0600-07FF reserved */
	hammer2_blockset_t freemap_blockset;	/* 0800-09FF freemap  */
	char	sector5[512];			/* 0A00-0BFF reserved */
	char	sector6[512];			/* 0C00-0DFF reserved */
	char	sector7[512];			/* 0E00-0FFF reserved */

	/*
	 * sector #8-71	- 32768 bytes
	 *
	 * Contains the configuration for up to 256 copyinfo targets.  These
	 * specify local and remote copies operating as masters or slaves.
	 * copyid's 0 and 255 are reserved (0 indicates an empty slot and 255
	 * indicates the local media).
	 *
	 * Each inode contains a set of up to 8 copyids, either inherited
	 * from its parent or explicitly specified in the inode, which
	 * indexes into this array.
	 */
						/* 1000-8FFF copyinfo config */
	hammer2_volconf_t copyinfo[HAMMER2_COPYID_COUNT];

	/*
	 * Remaining sections are reserved for future use.
	 */
	char		reserved0400[0x6FFC];	/* 9000-FFFB reserved */

	/*
	 * icrc on entire volume header
	 */
	hammer2_crc32_t	icrc_volheader;		/* FFFC-FFFF full volume icrc*/
};

typedef struct hammer2_volume_data hammer2_volume_data_t;

/*
 * Various parts of the volume header have their own iCRCs.
 *
 * The first 512 bytes has its own iCRC stored at the end of the 512 bytes
 * and not included the icrc calculation.
 *
 * The second 512 bytes also has its own iCRC but it is stored in the first
 * 512 bytes so it covers the entire second 512 bytes.
 *
 * The whole volume block (64KB) has an iCRC covering all but the last 4 bytes,
 * which is where the iCRC for the whole volume is stored.  This is currently
 * a catch-all for anything not individually iCRCd.
 */
#define HAMMER2_VOL_ICRC_SECT0		7
#define HAMMER2_VOL_ICRC_SECT1		6

#define HAMMER2_VOLUME_BYTES		65536

#define HAMMER2_VOLUME_ICRC0_OFF	0
#define HAMMER2_VOLUME_ICRC1_OFF	512
#define HAMMER2_VOLUME_ICRCVH_OFF	0

#define HAMMER2_VOLUME_ICRC0_SIZE	(512 - 4)
#define HAMMER2_VOLUME_ICRC1_SIZE	(512)
#define HAMMER2_VOLUME_ICRCVH_SIZE	(65536 - 4)

#define HAMMER2_VOL_VERSION_MIN		1
#define HAMMER2_VOL_VERSION_DEFAULT	1
#define HAMMER2_VOL_VERSION_WIP 	2

#define HAMMER2_NUM_VOLHDRS		4

union hammer2_media_data {
	hammer2_volume_data_t	voldata;
        hammer2_inode_data_t    ipdata;
	hammer2_blockref_t	npdata[HAMMER2_IND_COUNT_MAX];
	hammer2_bmap_data_t	bmdata[HAMMER2_FREEMAP_COUNT];
	char			buf[HAMMER2_PBUFSIZE];
};

typedef union hammer2_media_data hammer2_media_data_t;

#endif /* !_VFS_HAMMER2_DISK_H_ */