All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: james harvey <jamespharvey20@gmail.com>
Cc: kernel list <linux-kernel@vger.kernel.org>,
	martin.petersen@oracle.com, jaxboe@fusionio.com
Subject: Re: Interpreting /sys/block/<disk>/{,<partition>}/discard_alignment
Date: Thu, 10 Jan 2019 19:02:25 -0500	[thread overview]
Message-ID: <yq14lag12pa.fsf@oracle.com> (raw)
In-Reply-To: <CA+X5Wn4s2_zEvAHzT+dXToht=TBCyqBxVVnOPCrSTa_=_sxV6g@mail.gmail.com> (james harvey's message of "Wed, 9 Jan 2019 20:25:22 -0500")


James,

> 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.)

The alignment offset is the offset for the given block device. It
doesn't matter whether the block device in question is a partition, DM
device or a full device. A block device is a block device.

The common alignment scenario is 3584 on a device with 4K physical
blocks. That's because of the 63-sector legacy FAT partition table
offset. Which essentially means that the first LBA is misaligned and the
first aligned HBA is 7.

Many of the first 512e drives shipped with that intentional misalignment
as default. And you could switch it to 0-aligned via a jumper. These
days all drives are 0-aligned.

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

No, it needs to look at the device topology for the block device it is
on. I don't believe we ever wired up an ioctl for the discard alignment
so you'll have to find your device in sysfs. There's an alignment ioctl
for the "regular" block alignment, though.

-- 
Martin K. Petersen	Oracle Linux Engineering

  reply	other threads:[~2019-01-11  0:04 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-10  1:25 Interpreting /sys/block/<disk>/{,<partition>}/discard_alignment james harvey
2019-01-11  0:02 ` Martin K. Petersen [this message]
2019-01-11  2:47   ` james harvey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=yq14lag12pa.fsf@oracle.com \
    --to=martin.petersen@oracle.com \
    --cc=jamespharvey20@gmail.com \
    --cc=jaxboe@fusionio.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.