[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150817135450.GB27202@thunk.org>
Date: Mon, 17 Aug 2015 09:54:50 -0400
From: Theodore Ts'o <tytso@....edu>
To: Navin P <navinp1912@...il.com>
Cc: linux-kernel@...r.kernel.org
Subject: Re: Why is SECTOR_SIZE = 512 inside kernel ?
On Mon, Aug 17, 2015 at 06:23:04PM +0530, Navin P wrote:
>
> Why is SECTOR_SIZE 512 ?
>
> http://lxr.free-electrons.com/source/include/linux/ide.h#L118
>
> http://lxr.free-electrons.com/source/include/linux/device-mapper.h#L548
>
> 548 #define SECTOR_SHIFT 9
>
> I was looking at disks with hw_sector_size . Most of them i looked at
> had 512 bytes except for one which had 4096 (virtual disk). The one
> with AF format ie has logical sector size as 512 and hw_sector_size as
> 512 . So it is fine for my calculation from /proc/diskstats.
>
> But the one with 4096 logical and 4096 physical i multiply
> hw_sector_size with the sectors read and written but that is wrong
> since the kernel always defines sectors in terms of 512.
>
> Is it going to change or is it cast in stone ?
It's cast in stone. There are too many places all over the kernel,
especially in a huge number of file systems, which assume that the
sector size is 512 bytes. So above the block layer, the sector size
is always going to be 512.
This is actually *better* for user space programs using
/proc/diskstats, since they don't need to know whether a particular
underlying hardware is using 512, 4k, (or if the HDD manufacturers
fantasies become true 32k or 64k) sector sizes.
For similar reason, st_blocks in struct size is always in units of 512
bytes. We don't want to force userspace to have to figure out whether
the underlying file system is using 1k, 2k, or 4k. For that reason
the units of st_blocks is always going to be 512 bytes, and this is
hard-coded in the POSIX standard.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists