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
