Lines Matching +full:64 +full:mb
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.
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
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 */
128 * HAMMER2_SEGSIZE - Allocation map segment size, typically 4MB
141 * Generally speaking we want to use 16K and 64K I/Os
168 * Indirect blocks are typically either 4KB (64 blockrefs / ~4MB represented),
169 * or 64KB (1024 blockrefs / ~64MB represented).
189 * A 4MB segment is reserved at the beginning of each 2GB zone. This segment
191 * table, and possibly other information in the future. A 4MB segment for
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
266 * (256 x struct hammer2_bmap_data). Each structure represents 4MB of storage
293 * (i.e. a multiple of 4MB). VOLUME_ALIGN must be >= ZONE_SEG.
353 #define HAMMER2_ZONE_END 64 /* non-inclusive */
360 #define HAMMER2_ZONEFM_LEVEL3 2 /* 64TB indmap */
369 * Leaf entry represents 4MB of storage broken down into a 512-bit
375 #define HAMMER2_FREEMAP_LEVEL6_RADIX 64 /* 16EB (end) */
378 #define HAMMER2_FREEMAP_LEVEL3_RADIX 46 /* 64TB */
381 #define HAMMER2_FREEMAP_LEVEL0_RADIX 22 /* 4MB (128by in l-1 leaf) */
426 * 8 x 64-bit elements, 2 bits per block.
435 #define HAMMER2_BMAP_BITS_PER_ELEMENT 64
448 * Two linear areas can be reserved after the initial 4MB segment in the base
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
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
870 * only. May contain values between 0 and 4MB. Must be ignored
893 * 64-bit elements, 256x2 bits representing ~4MB worth of media
913 /* 40-7F 512 bits manages 4MB of storage */
938 * blockrefs, in turn, are indexed by the 64-bit directory hash key. Remember
1061 union { /* 0200-03FF (64x8 = 512 bytes) */
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,