1.1.b hdd block sector
0 likes115 views
Block size is a multiple of sector size to allow for more efficient reading and writing to disks. While some wasted space occurs when file sizes do not exactly match block sizes, this is necessary to reduce disk fragmentation and improve performance. Larger block sizes allow for sequential access of data in blocks, reducing disk seeks and improving throughput for both reads and writes. Though some space is wasted, it is outweighed by the performance benefits of working with disk blocks.
1.1.b 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.