hdd block sector

1. Embora seja fora de âmbito com relação directa nas especificidades do hardware, possui
algum enquadramento pertinente na melhor conceptualização e contextualização de
aspectos relacionados com o Linux (e com todos os SO’s).
Nesse sentido fruto do nosso diálogo em sessão, segue alguns aspectos que colectei para de
forma sucinta contextualizarem e eventualmente corrigirem alguma imprecisão que tenha
sido mal esclarecida.
Na relação que existe com nos discos rígidos, entre sectores, blocos e taxa perdida de
endereçamento lógico dos ficheiros nos blocos.
1. On reading through disc structure, it states that blocks size is a multiple of sector size. First
thought is why do you even need blocks when there are sectors, and secondly why is the block
size a multiple of sector like 1,2,4? Why can't it be half of sector? What's the relation here?
Early in the computing industry, the term "block" was loosely used to refer to a small chunk of data.
Later the term referring to the data area was replaced by sector, and block became associated with the
data packets that are passed in various sizes by different types of data streams.
http://en.wikipedia.org/wiki/Disk_sector
Block is an abstraction of filesystems. All filesystem operations can be accessed only in multiple of
blocks. In other terms, the smallest logically addressable unit to filesystem is block, not a sector.
The smallest addressable unit on a block device is a sector. The sector size is physical property of a
block device and is the fundamental unit of all block devices.
Most block devices have 512‐byte sectors (although other sizes are common. For example, some CD‐
ROM discs have 2‐kilobyte sectors) while block sizes are commonly of size 512 bytes, 1 KB or 4KB. This is
the reason block size is a multiple of sector.
2. Disk Sector and Wasted Block Allocation For Files.
A sector is a unit normally 512 bytes or 1k, 2k, 4k… with relation to space in disk hardware.
Filesystem block size is group of sector size.
Suppose I am storing a file which is 5KB, how this will be written onto disk if a sector is 512 bytes
and block is 4KB? 4KB of that File is written into one block and another 1KB of file is written into
antoher 4KB Block. Now 3KB of that second Block is unusable. Will it be usable in future or will it
be wasted? If I write the 10 5KB file to disk, 30KB of size will be wasted, or this 30KB is used in
disk usage?
First thing to note, is that the block size is almost always larger than your sector size
To determine sector size run the following command
root@ubuntu:~# fdisk ‐l | grep ‐E "Sector size"
Sector size (logical/physical): 512 bytes / 512 bytes
Sector size will almost always be either 512 bytes or 4096 bytes.
To determine block size, run the following command
root@ubuntu:~# blockdev ‐‐getbsz /dev/sda
4096
The block size will often be 4096 on most modern OSes. You can change this if desired
Any files that do not completely fill a block, will result in wasted space. This is normal and expected.

2. http://linux.die.net/man/8/blockdev
http://serverfault.com/questions/29887/how‐do‐i‐determine‐the‐block‐size‐of‐an‐ext3‐partition‐on‐linux
http://www.linuxforums.org/forum/miscellaneous/5654‐linux‐disk‐block‐size‐help‐please.html
Its a well established fact that files are stored on disk in multiples of "block" size.
The concept of a block began as a simple way for physical sectors on disk to be represented logically in
the filesystem. Each sector had its own header, data area and ECC which made it the smallest piece of
disk that could be independently represented logically.
As time went by, with the advent of caches on the HDD controller it became easier to have logical
blocks which were of the size of multiple physical sectors. This way on‐disk sequential I/O increased
resulting in better throughput.
Today, a block is the smallest piece of disk‐space available. Typically files are stored using 1 or more
block(s) on disk.
For each file, the leftover space (if any) in the last
block is used whenever changes are made to the file
and it "grows", requiring additional disk‐space to
store the newly added content.
Additional space requirement (beyond what the free
space in the current last block can accommodate) is
satisfied by requesting additional blocks on the disk
and logically linking the new set of blocks to continue
following the current last block of the file.
File A illustrates the above scenario.

3. Advantage of allocating blocks in advance is that fragmentation is reduced. Consider the alternative
where there is no concept of blocks on disk and disk‐space is allocated as required i.e the amount of disk
space allocated is exactly the file size.
In such a setup, each time even a single character is added to the file, one would need to :
 Allocate additional memory (1 more character).
 Setup a link between the area containing the initial area of the file and this new byte.
All this meta‐data i.e. additional formation about the "links" requires disk‐space too. This constitutes a
fixed overhead for each such "link" and hence its imperative that such "links" be kept to a minimal
number. The concept of allocating disk size in "blocks" limits the overhead to a pre‐determined amount.
Guaranteed number of files on disk = Raw disk‐space / block‐size
Also such random seeking reduces throughput as repositioning the disk head is the most time‐
consuming task involved in disk I/O. Frequent random seeking is also likely to wear out the disk faster
(remember dancing HDDs?) and must be avoided as much as possible.
Further advantages of this approach :
1. Faster reads ‐ Using blocks, disk reads are sequential upto the block size. Less seeks = higher read
throughput.
2. Faster Writes ‐ Blocks provide a simple implementation that can be mapped to pages which results
in higher write throughput as well.