Hi On Fri, Nov 21, 2014 at 04:20:07PM +0500, Muhammad Yousuf Khan wrote: > Dear experts, > > i know its frustrating because i always ask theoretical question. i hope and > believe you guyz will not mind and i really learn alot from this list. > > So, coming to the point, I want to clear my confusion on block size. > theoretically i know what block size is but practically i dont know that what > are the reasons that one might want to change the block size and how it > effects > the IO performance.
Well.. Block sizes exist at multiple levels... The physical disk will have "blocks" - i.e. all physical reads and writes happen in multiple of blocks. To change one byte, the whole block has to be read into memory, the byte change in memory, the whole block written out again. Nowadays disks may hide this in their interface, but on the physical media (I'm thinking of spinning rusty platters), we still have to obey the laws of physics. Changing the magnetisation of a single spot is on neigh-impossible without distorting the surrounding magnetic fields, so blocks have gaps between them to allow for this. Obviously things are different on SSDs. A different "block" concept also exists at the file system level for the purposes of allocation - disk space can be allocated in units of blocks. For file systems with a few big files, bigger block sizes are good -> means fewer total blocks to keep track of and probably less fragmentation. For file systems with lots of little files, smaller block sizes will tend to waste less space. And then there is the massive grey area in between.... If you are using LVM, this also has "extents" which is the unit of allocation here. > i have heard that people would want to use bigger block size if they are > hosting or storing big files like videos, or other big size data. on the other > hand people recommends to use small size when we have many small > files. Yes - this is the block size concept for allocation. > actually i know the science behind that if i create a bigger block size and > file size is small it will create the same size file as block size which end > up > eating space when we have large database of small file. Usually, yes. It really depends on the filesystem you use. I believe it to be true for ext3, and (probably) also for ext4. But reiserfs, btrfs and others have some optimisations in this area, where small files are stored in the directory. But here we're talking about file system internals. > > so in context of above. my questions are. > > why to change the block size? and what are the basic reasons that make some > one > to think about that? Usually, there are two desires pulling in different directions: Performance and disk usage efficiency. And what is best for one use case may be unacceptable for a different use case. When we throw other concepts like resilience and backups into the mix, things get murkier still. > > did it really help in increasing the performance by changing the block size? > > can it effect the RAID (mdadm) or hardware RAID performance if we change the > block size? Yes :-) > what is the deference b/w block size and cylinder. ? http://en.wikipedia.org/wiki/Cylinder-head-sector > > why it is recommended that we should use same size of block in both VG and LV > as the size of PV? This could possible be due to alignment.... -- Karl E. Jorgensen -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141121124135.GD26871@hawking