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
  • 9
  • Authoritative I don't know, but I can tell you fdisk tells you logical and physical sector size, and the `/sys/block//size` reports the size in logical sector size. Unfortunately I have no experience with drives that don't emulate 512 bytes (they are rare-ish). I can also tell you that WDC WD15EARS have 4k sectors, but report 512 physical and logical... Good luck with all that :)! – Halfgaar Sep 24 '18 at 19:51
  • I thought it would be a simple empirical question, ie it should just say somewhere in the linux code or documentation base, especially given the other ABI values are fully explained, this question may actually be worth following through on, particularly since people are linking to an "answer" that is not actually an answer, although it very much appears to be one. I can't dig through all the kernel code though to find it, so I'm hoping someone actually knows either where answer is, or why that patch was not used in the end. Odd that /sys/block///block_logical_size missing. – Lizardx Sep 24 '18 at 20:05

1 Answers1

2

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
  • 47,711
  • 7
  • 111
  • 180
  • I forgot, I'd come across that source code as well, but given the patch to actually document this was not apparently applied, I did not trust that this was the reality. /proc/partitions may be the better way to go, I forgot to confirm if that was the available or full partition size, it does seem to be the full, so that's the easier way, agreed, requires less parsing to get to the partition data. blockdev requires root, which I'm trying to avoid. I'm going to leave this a bit before accepting this answer because the question remains why the docs do not show the 512 patch. – Lizardx Sep 24 '18 at 20:34