What does the output of fdisk mean?

Solution 1:

Size of a Block

A 3-dimensional track (the same track on all disks) is called a cylinder. Each track is divided into 63 sectors. Each sector contains 512 bytes of data. Therefore the block size in the partition table is 64 heads * 63 sectors * 512 bytes er... divided by 1024... :-)

Source: Partitioning with fdisk

Any time Linux refers to block size, it is almost always 1024 bytes - Linux uses 1024-byte blocks as its primitive units for the buffer cache and everything The only times it isn't is in filesystem-specific drivers, since some filesystems use other granularities (for example, on a normal-sized ext3 filesystem, the filesystem block size is usually 4096 bytes). However, you almost never get to see the filesystem block size; almost the only way to actually see it is to be a kernel hacker or run programs like dumpe2fs.

The problem with this is that there are four distinct units that you must be keeping in mind. To make things even worse, two of these units bear the same name. These are the different units:

  1. Hardware block size, "sector size"
  2. Filesystem block size, "block size"
  3. Kernel buffer cache block size, "block size"
  4. Partition table block size, "cylinder size"

To differentiate between the filesystem block size and the buffer cache block size, I will follow FAT terminology and use "cluster size" for the filesystem block size.

The sector size is the units that the hardware deals with. This ranges between different hardware types, but most PC-style hardware (floppies, IDE disks, etc.) use 512 byte sectors.

The cluster size is the allocation unit that the filesystem uses, and is what causes fragmentation - I'm sure you know about that. On a moderately sized ext3 filesystem, this is usually 4096 bytes, but you can check that with dumpe2fs. Remember that these are also usually called "blocks", only that I refer to them as clusters here. The cluster size is what gets returned in st_blksize in the stat buffer, in order for programs to be able to calculate the actual disk usage of a file.

The block size is the size of the buffers that the kernel uses internally when it caches sectors that have been read from storage devices (hence the name "block device"). Since this is the most primitive form of storage in the kernel, all filesystem cluster sizes must be multiples of this. This block size is also what is almost always referred to by userspace programs. For example, when you run du without the -h or -H options, it will return how many of these blocks a file takes up. df will also report sizes in these blocks, the "Blocks" column in the fdisk -l output is of this type, and so on. It is what is most commonly referred to as a "block". Two disk sectors fit into each block.

The cylinder size is only used in the partition table and by the BIOS (and the BIOS isn't used by Linux).

Source: Linux disk block size... help please

Sectors 0-31

To answer your question about the first 32 sectors, as the flash drive is a FAT formatted device then looking at the FAT file system definition, one can see that a FAT file system is composed of four different sections:

a) The Reserved Sectors;
b) The File Allocation Table (FAT) region;
c) The Root Directory Region, and;
d) The Data Region.

Fat Overview

The Reserved Sectors, located at the very beginning, are (in this case) the sectors 0-31:

The first reserved sector (logical sector 0) is the Boot Sector (aka Volume Boot Record (VBR)). It includes an area called the BIOS Parameter Block (with some basic file system information, in particular its type, and pointers to the location of the other sections) and usually contains the operating system's boot loader code.

Important information from the Boot Sector is accessible through an operating system structure called the Drive Parameter Block (DPB) in DOS and OS/2.

The total count of reserved sectors is indicated by a field inside the Boot Sector, and is usually 32 on FAT32 file systems.

For FAT32 file systems, the reserved sectors include a File System Information Sector at logical sector 1 and a Backup Boot Sector at logical sector 6.

While many other vendors have continued to employ a single-sector setup (logical sector 0 only) for the bootstrap loader, Microsoft's boot sector code has grown to spawn over logical sectors 0 and 2 since the introduction of FAT32, with logical sector 0 depending on sub-routines in logical sector 2. The Backup Boot Sector area consists of three logical sectors 6, 7, and 8 as well. In some cases, Microsoft also uses sector 12 of the reserved sectors area for an extended boot loader.


Just additional information, not relevant to the OP question

The FAT Region, will be at sector 32:

This typically contains two copies (may vary) of the File Allocation Table for the sake of redundancy checking, although rarely used, even by disk repair utilities.

These are maps of the Data Region, indicating which clusters are used by files and directories. In FAT12 and FAT16 they immediately follow the reserved sectors.

Typically the extra copies are kept in tight synchronisation on writes, and on reads they are only used when errors occur in the first FAT. In FAT32, it is possible to switch from the default behaviour and select a single FAT out of the available ones to be used for diagnosis purposes.

The first two clusters (cluster 0 and 1) in the map contain special values.

The Root Directory Region:

This is a Directory Table that stores information about the files and directories located in the root directory. It is only used with FAT12 and FAT16, and imposes on the root directory a fixed maximum size which is pre-allocated at creation of this volume. FAT32 stores the root directory in the Data Region, along with files and other directories, allowing it to grow without such a constraint. Thus, for FAT32, the Data Region starts here.

The Data Region:

This is where the actual file and directory data is stored and takes up most of the partition. Traditionally, the unused parts of the data region are initialised with a filler value of 0xF6 as per the INT 1Eh's Disk Parameter Table (DPT) during format on IBM compatible machines, but also used on the Atari Portfolio. 8-inch CP/M floppies typically came pre-formatted with a value of 0xE5; by way of Digital Research this value was also used on Atari ST formatted floppies. Amstrad used 0xF4 instead. Some modern formatters wipe hard disks with a value of 0x00, whereas a value of 0xFF, the default value of a non-programmed flash block, is used on flash disks to reduce wear. The latter value is typically also used on ROM disks. (Some advanced formatting tools allow to configure the format filler byte.)

The size of files and subdirectories can be increased arbitrarily (as long as there are free clusters) by simply adding more links to the file's chain in the FAT. Note however, that files are allocated in units of clusters, so if a 1 KiB file resides in a 32 KiB cluster, 31 KiB are wasted.

FAT32 typically commences the Root Directory Table in cluster number 2: the first cluster of the Data Region.

Source: Wikipedia - File Allocation Table

Solution 2:

I am guessing that the sectors 1-31 are reserved for boot information and partition table info. The partition /dev/sdb1 starts at block/sector 32 and goes to 249854. It is a logical partition on the physical disk.

The 124911+ is giving you the count of blocks between 32 and 249854.

About Disk Geometry here is what man fdsik says about it:

If possible, fdisk will obtain the disk geometry automatically. This is not necessarily the physical disk geometry (indeed, modern disks do not really have anything like a physical geometry, certainly not something that can be described in simplistic Cylinders/Heads/Sectors form), but it is the disk geometry that MS-DOS uses for the partition table.

Usually all goes well by default, and there are no problems if Linux is the only system on the disk. However, if the disk has to be shared with other operating systems, it is often a good idea to let an fdisk from another operating system make at least one partition. When Linux boots it looks at the partition table, and tries to deduce what (fake) geometry is required for good cooperation with other systems.