3

My primary question is to authoritatively see if the block size used in sector counts: 

/sys/block/<disk>/<partition>/size

is in fact 512 B, or if this can vary.

I thought this would be fairly easy to find an answer to, but for example here:

https://lore.kernel.org/lkml/201012011729.18661.lists@egidy.de/T/#u

the question was asked:

There are /sys/block/<device>/size and 
/sys/block/<device>/<device><partition>/size.

But these values are reported in sectors, not in bytes. As discs with 4K 
sectors are on the horizon now, I don't want to make wrong assumptions on the 
sector size.

So what is the correct sector size for /sys/block/<device>/size?

And a patch was offered in the documentation to apparently once and for all answer this question in documentation: https://lore.kernel.org/lkml/1451154995-4686-1-git-send-email-peter@lekensteyn.nl/T/

As the meaning has not changed for over 13 years, I would like to formalize these attributes such that users can rely on it[1][2]. The sector definition was inspired by the block/stat.txt documentation.

With the patch: 

diff --git a/Documentation/ABI/testing/sysfs-block   b/Documentation/ABI/testing/sysfs-block
+What:      /sys/block/<disk>/<partition>/size
+Date:      October 2002
+Contact:   linux-block@vger.kernel.org
+Kernel Version:    2.5.43
+Description:
+       Size of the partition in standard UNIX 512-byte sectors
+       (not a device-specific block size).

Which all seems straightforward, but when I look up the current existing doc: https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-block

There is no presence of this patch. Which suggests that in fact this apparently simple question may not be simple?

Can someone point me to an actual authoritative answer to this question, ideally using kernel documentation or code with comments?

Currently I'm relying on the output of a tool, but if that is not in fact always 512B that output could be wrong, which would lead the code I'm working on to be wrong as well in some cases.

I'm surprised it's been so difficult to find a truly authoritative answer,

https://unix.stackexchange.com/questions/52215/determine-the-size-of-a-block-device

Units for size in /proc/partitions don't make sense

Some of these point to the patch here, but none seem to be aware that the patch does not seem to have been accepted, though it appears to be have been signed off, yet it's not in the documentation code as far as I can see.

It would be nice if we could once and for all determine what the internal kernel code really is doing, and if this behavior is documented, or merely assumed, which means it could in theory randomly change at any time.

Lizardx
  • 210
  • 1
  • 10

1 Answers1

3

From Linux source code comment:

Linux always considers sectors to be 512 bytes long independently of the devices real block size

That said, I think scanning /sys/block/<disk>/ is the worst (or at least harder) approach from the ones available to get disks and partitions size:

  • lsblk --bytes --list produce an informative, non-ambiguous and parseable output;
  • cat /proc/partitions give similar information in 1K-sized blocks
  • blockdev --getsize64 <dev> returns device size in bytes;
  • blockdev --getsz <dev> returns device size in 512-bytes sectors;
  • ... surely other methods which I don't remember now ...
shodanshok
  • 52,255