Lines Matching +full:256 +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.
260 * Each freemap set is 5 x 64K blocks and represents the 1GB, 256GB, 64TB,
265 * The Level 0 64KB block represents 1GB of storage represented by 32KB
266 * (256 x struct hammer2_bmap_data). Each structure represents 4MB of storage
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
359 #define HAMMER2_ZONEFM_LEVEL2 1 /* 256GB indmap */
367 * 32KB indirect block for freemap (LEVELN_PSIZE below).
370 * bitmap, 2-bits per entry. So course bitmap item represents 16KB.
379 #define HAMMER2_FREEMAP_LEVEL2_RADIX 38 /* 256GB */
417 * 16KB bitmap granularity (x2 bits per entry).
455 #define HAMMER2_BOOT_MAX_BYTES (256*1024*1024)
458 #define HAMMER2_REDO_NOM_BYTES (256*1024*1024)
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
659 * CONTENT ADDRESSABLE INDEXING (future) - Using a 256 or 512-bit check code.
682 * HAMMER2_ALLOC_MIN (at least 256, typically 1024).
835 * Indirect blocks are typically 4KB (64 entres) or 64KB (1024 entries) and
861 * a LEVEL0 (4MB) block of storage. The storage is managed in 256 x 16KB
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
893 * 64-bit elements, 256x2 bits representing ~4MB worth of media
912 uint32_t reserved20[8]; /* 20-3F 256 bits manages 128K/1KB/2-bits */
929 * The inode is 1024 bytes, made up of 256 bytes of meta-data, 256 bytes
963 #define HAMMER2_INODE_MAXNAME 256 /* maximum name in bytes */
1060 /* 0100-01FF (256 char, unterminated) */
1087 #define HAMMER2_COPYID_COUNT 256
1157 * Note that the minimum chunk size is 1KB so we could theoretically have
1159 * chunk size down to 256 bytes and if so we will need bits 8 and 9.
1320 * Contains the configuration for up to 256 copyinfo targets. These
1354 * The whole volume block (64KB) has an iCRC covering all but the last 4 bytes,