Lines Matching +full:128 +full:kb

76  * are always 64KB.  Logical file buffers are typically 16KB.  All data
85  * to optimize storage efficiency.  The minimum fragment size is 1KB.
94  * A full indirect block use supports 512 x 128-byte blockrefs in a 64KB
95  * buffer.  Indirect blocks down to 1KB are supported to keep small
99  * using 64KB indirect blocks (128 byte refs, 512 or radix 9 per indblk).
165  * <= 512KB.  Up to 4 directory entries can be referenced from a directory
168  * Indirect blocks are typically either 4KB (64 blockrefs / ~4MB represented),
169  * or 64KB (1024 blockrefs / ~64MB represented).
198  *  1 freemap00 level1 FREEMAP_LEAF (256 x 128B bitmap data per 1GB)
199  *  2           level2 FREEMAP_NODE (256 x 128B indirect block per 256GB)
200  *  3           level3 FREEMAP_NODE (256 x 128B indirect block per 64TB)
201  *  4           level4 FREEMAP_NODE (256 x 128B indirect block per 16PB)
202  *  5           level5 FREEMAP_NODE (256 x 128B indirect block per 4EB)
247  * Note that each FREEMAP_LEAF or FREEMAP_NODE uses 32KB out of 64KB slot.
265  * The Level 0 64KB block represents 1GB of storage represented by 32KB
267  * and has a 512 bit bitmap, using 2 bits to represent a 16KB chunk of
275  * One important thing to note here is that the freemap resolution is 16KB,
276  * but the minimum storage allocation size is 1KB.  The hammer2 vfs keeps
278  * the entire 16KB of a partially allocated block will be considered fully
366  * Freemap radix.  Assumes a set-count of 4, 128-byte blockrefs,
367  * 32KB indirect block for freemap (LEVELN_PSIZE below).
370  * bitmap, 2-bits per entry.  So course bitmap item represents 16KB.
381 #define HAMMER2_FREEMAP_LEVEL0_RADIX	22	/* 4MB (128by in l-1 leaf) */
417  * 16KB bitmap granularity (x2 bits per entry).
492  * minimum allocation chunk size is 1KB (a radix of 10), so HAMMER2 sets
493  * HAMMER2_RADIX_MIN to 10.  The maximum radix is currently 16 (64KB), but
546  * WARNING!  This structure must be exactly 128 bytes long for its config
603  * media topology recursion.  This 128-byte data structure is embedded in the
617  * blockref but later expanded it to 128 bytes to be able to support the
743 #define HAMMER2_BLOCKREF_BYTES		128	/* blockref struct in bytes */
751  * types >= 128 are pseudo values that should never be present on-media.
835  * Indirect blocks are typically 4KB (64 entres) or 64KB (1024 entries) and
860  * Each 128-byte entry contains the bitmap and meta-data required to manage
861  * a LEVEL0 (4MB) block of storage.  The storage is managed in 256 x 16KB
867  * (data structure must be 128 bytes exactly)
869  * linear  - A BYTE linear allocation offset used for sub-16KB allocations
871  *	     if 16KB-aligned (i.e. force bitmap scan), otherwise may be
872  *	     used to sub-allocate within the 16KB block (which is already
875  *	     Sub-allocations need only be 1KB-aligned and do not have to be
876  *	     size-aligned, and 16KB or larger allocations do not update this
881  *	     desire to support sector sizes up to 16KB (so H2 only issues
882  *	     I/O's in multiples of 16KB anyway).
892  * bitmap  - Two bits per 16KB allocation block arranged in arrays of
912 	uint32_t reserved20[8];	/* 20-3F 256 bits manages 128K/1KB/2-bits */
1157  * Note that the minimum chunk size is 1KB so we could theoretically have
1354  * The whole volume block (64KB) has an iCRC covering all but the last 4 bytes,