linux-kernel - Interpreting /sys/block/<disk>/{,<partition>}/discard

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+X5Wn4s2_zEvAHzT+dXToht=TBCyqBxVVnOPCrSTa_=_sxV6g@mail.gmail.com>
Date:   Wed, 9 Jan 2019 20:25:22 -0500
From:   james harvey <jamespharvey20@...il.com>
To:     kernel list <linux-kernel@...r.kernel.org>,
        martin.petersen@...cle.com, jaxboe@...ionio.com
Subject: Interpreting /sys/block/<disk>/{,<partition>}/discard_alignment

https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-block

Describes discard_alignment as:

"Devices that support discard functionality may internally allocate
space in units that are bigger than the exported logical block size.
The discard_alignment parameter indicates how many bytes the beginning
of the device is offset from the internal allocation unit's natural
alignment."

Q1 - I'm hoping you can clarify how this should be interpreted.

I originally took this to mean the number of bytes into the first
discard_granularity block that the partition resides at.  i.e.  If
discard_granularity_block is 128MB, and partition 1 starts at sector
2048 with 512 byte sectors, that this should return 2048*512=1048576
(1MB.)

However, LVM thin volumes (using device mapper thin pools) are seeming
to give the number of bytes left in the first discard_granularity
block at the beginning of the partition.  i.e. Returning
discard_granularity of 128 * 1024 * 1024 minus the start of the
partition 2048 * 512, or 133169152.  (This is if the thin volume is
created with a chunk size of 128MB.)

Q2 - At https://lkml.org/lkml/2018/12/5/1693 --- I saw you recently
said "... there are not many devices that actually report a non-zero
discard alignment..."  Does this mean that every filesystem needs to
look at the partition table to determine its correct value on its own,
rather than using discard_alignment?