Lines Matching +full:64 +full:kb
44 * dmsg_hdr must be 64 bytes
76 * are always 64KB. Logical file buffers are typically 16KB. All data
77 * references utilize 64-bit byte offsets.
85 * to optimize storage efficiency. The minimum fragment size is 1KB.
89 * For the moment the maximum allocation size is HAMMER2_PBUFSIZE (64K),
91 * fragments might be supported in the future (down to 64 bytes is possible),
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
98 * A maximally sized file (2^64-1 bytes) requires ~6 indirect block levels
99 * using 64KB indirect blocks (128 byte refs, 512 or radix 9 per indblk).
111 #define HAMMER2_RADIX_KEY 64 /* number of bits in key */
141 * Generally speaking we want to use 16K and 64K I/Os
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).
194 * 4MB = 64 x 64K blocks. Each 4MB segment is broken down as follows:
200 * 3 level3 FREEMAP_NODE (256 x 128B indirect block per 64TB)
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,
262 * blockrefs representing another 2 bits, giving us a total 64 bits of
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
353 #define HAMMER2_ZONE_END 64 /* non-inclusive */
360 #define HAMMER2_ZONEFM_LEVEL3 2 /* 64TB indmap */
367 * 32KB indirect block for freemap (LEVELN_PSIZE below).
370 * bitmap, 2-bits per entry. So course bitmap item represents 16KB.
375 #define HAMMER2_FREEMAP_LEVEL6_RADIX 64 /* 16EB (end) */
378 #define HAMMER2_FREEMAP_LEVEL3_RADIX 46 /* 64TB */
417 * 16KB bitmap granularity (x2 bits per entry).
426 * 8 x 64-bit elements, 2 bits per block.
435 #define HAMMER2_BMAP_BITS_PER_ELEMENT 64
454 #define HAMMER2_BOOT_NOM_BYTES (64*1024*1024)
462 * Most HAMMER2 types are implemented as unsigned 64-bit integers.
485 * All HAMMER2 data offsets have to be broken down into a 64K buffer base
486 * offset (HAMMER2_OFF_MASK_HI) and a 64K buffer index (HAMMER2_OFF_MASK_LO).
488 * Indexes into physical buffers are always 64-byte aligned. The low 6 bits
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
561 uint8_t path[64]; /* 40-7F target specification string or key */
615 * The check code can be a simple 32-bit iscsi code, a 64-bit crc, or as
616 * complex as a 512 bit cryptographic hash. I originally used a 64-byte
661 struct hammer2_blockref { /* MUST BE EXACTLY 64 BYTES */
680 * NOTE: check.buf contains filename if <= 64 bytes. Longer
701 char buf[64];
719 char data[64];
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 */
938 * blockrefs, in turn, are indexed by the 64-bit directory hash key. Remember
1061 union { /* 0200-03FF (64x8 = 512 bytes) */
1157 * Note that the minimum chunk size is 1KB so we could theoretically have
1177 * The volume header eats a 64K block. There is currently an issue where
1354 * The whole volume block (64KB) has an iCRC covering all but the last 4 bytes,