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]
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?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ