Lines Matching +full:512 +full:mb

94  * A full indirect block use supports 512 x 128-byte blockrefs in a 64KB
99  * using 64KB indirect blocks (128 byte refs, 512 or radix 9 per indblk).
128  * HAMMER2_SEGSIZE	- Allocation map segment size, typically 4MB
163  * Inodes embed either 512 bytes of direct data or an array of 4 blockrefs,
164  * resulting in highly efficient storage for files <= 512 bytes and for files
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).
173 #define HAMMER2_EMBEDDED_BYTES		512	/* inode blockset/dd size */
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:
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
293  *	     (i.e. a multiple of 4MB).  VOLUME_ALIGN must be >= ZONE_SEG.
369  * Leaf entry represents 4MB of storage broken down into a 512-bit
381 #define HAMMER2_FREEMAP_LEVEL0_RADIX	22	/* 4MB (128by in l-1 leaf) */
448  * Two linear areas can be reserved after the initial 4MB segment in the base
616  * complex as a 512 bit cryptographic hash.  I originally used a 64-byte
659  * CONTENT ADDRESSABLE INDEXING (future) - Using a 256 or 512-bit check code.
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 */
930  * for the filename, and 512 bytes worth of direct file data OR an embedded
942  * Up to 512 bytes of direct data can be embedded in an inode, and since
1061 	union {				/* 0200-03FF (64x8 = 512 bytes) */
1178  * we want to try to fit all nominal filesystem updates in a 512-byte section
1227 	 * sector #0 - 512 bytes
1286 	 * 32 bit CRC array at the end of the first 512 byte sector.
1288 	 * icrc_sects[7] - First 512-4 bytes of volume header (including all
1291 	 * icrc_sects[6] - Sector 1 (512 bytes) of volume header, which is
1301 	 * sector #1 - 512 bytes
1310 	char	sector2[512];			/* 0400-05FF reserved */
1311 	char	sector3[512];			/* 0600-07FF reserved */
1313 	char	sector5[512];			/* 0A00-0BFF reserved */
1314 	char	sector6[512];			/* 0C00-0DFF reserved */
1315 	char	sector7[512];			/* 0E00-0FFF reserved */
1348  * The first 512 bytes has its own iCRC stored at the end of the 512 bytes
1351  * The second 512 bytes also has its own iCRC but it is stored in the first
1352  * 512 bytes so it covers the entire second 512 bytes.
1364 #define HAMMER2_VOLUME_ICRC1_OFF	512
1367 #define HAMMER2_VOLUME_ICRC0_SIZE	(512 - 4)
1368 #define HAMMER2_VOLUME_ICRC1_SIZE	(512)