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:
- Hardware block size, "sector size"
- Filesystem block size, "block size"
- Kernel buffer cache block size, "block size"
- 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.
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
Best Answer
In the PCI/PCI-X/PCI-E devices, there are BARs registers in the PCI configuration space. And during Linux Kernel booting up, it will scan the PCI bus, find all PCI devices including PCI-to-PCI bridge and PCI devices. And kernel will check how many BARs are there in the PCI devices' configuration space. And check how much memory space each BAR needs and the memory space type by writing 0xFFFFFFFF to BAR register. Then kernel will allocate the memory space resources to the PCI devices.
In your case, Region lion is show the BAR registers.
In each device driver corresponding, one can get the base physical address that Linux Kernel allocate for each BAR by calling pci_resource_start(), and call pci_iomap() to map the base physical address to kernel virtual address, or using remap_pfn_range() to implement one mmap method for user space process to map the physical address to user space process virtual address.