Info

union swap_header { struct

char reserved[PAGE_SIZE char magic[10];

/* SWAP-SPACE or SWAPSPACE2 */

struct {

char

_u32

_u32

_u32

unsigned char unsigned char

_u32

bootbits[1024];

version;

last_page;

nr_badpages;

sws_volume[16];

padding[117];

badpages[1];

The union allows identical data to be interpreted in different ways, as illustrated in Figure 18-2.

□ The first 1,024 bytes are left free to create space for boot loaders that on some architectures must be present at defined places on the hard disk. This enables swap areas to be positioned right at the start of a disk on such architectures even though boot loader code is also located there.

□ Details of the swap area version (version) then follow, plus the number of the last page (nr_lastpage) and the number of unusable pages (nr_badpages). A list with the number of unusable blocks follows after 117 integer filler entries, which can be used for additional information in any new versions of the swap format. Even if formally this list has only one element in the data structure, it has in reality nr_badpages members.

label and uuid allow associating a label and a UUID (Universally Unique Identifier) with a swap partition. The kernel does not use these fields, but they are required by some userland tools (the manual page blkid8 provides more information about the rationale behind these identifiers).

struct info

"SWAPSPACE2 struct swap_header

Figure 18-2: Layout of the swap header.

The reason why two data structures are used to analyze this information is historical (new information is created only in areas that were not used by the old format — in other words, between the 1,024 reserved bytes at the start of the partition and the signature at the end), but is also partly because the kernel must be able to handle different page sizes, and this is simpler if different structures are used. Since information is located at the start and at the end of the first swap page, the space between must be filled with a suitable number of empty filler elements — at least from the data structure's viewpoint. However, access to the swap signature at the bottom end of the page is easier if the fill space required is calculated by simply deducting the length of the signature (10 characters) from the page size — which is specified by page_size on all architectures. This yields the required position. When the upper elements are accessed, it is only necessary to specify the definition of the upper part. From the viewpoint of the data structure, the data that then follow are of no interest since they merely contain the list of bad blocks whose array position addresses can be calculated very easily.

Continue reading here: Creating the Extent List

Was this article helpful?

0 0