From: james harvey <jamespharvey20@gmail.com>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: kernel list <linux-kernel@vger.kernel.org>, jaxboe@fusionio.com
Subject: Re: Interpreting /sys/block/<disk>/{,<partition>}/discard_alignment
Date: Thu, 10 Jan 2019 21:47:03 -0500 [thread overview]
Message-ID: <CA+X5Wn5LH149=sDXqL-O9j1qMjNUVTrucnfyGyN_=ujPOun2dQ@mail.gmail.com> (raw)
In-Reply-To: <yq14lag12pa.fsf@oracle.com>
On Thu, Jan 10, 2019 at 7:04 PM Martin K. Petersen
<martin.petersen@oracle.com> wrote:
> 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.
If I can double check I'm understanding you correctly, if:
* Block device "A" has 512 byte sectors
* A has a partition table with partition A1 starting at sector 2048
(1048576 bytes)
* A and A1 have discard_granularity of 128MB (134217728 bytes)
* A has discard_alignment of 0
Then A1 should have a discard_alignment of 1048576, not 133169152
(128MB - 512 bytes/sector * 2048 sectors)?
> 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.
Ahh, good. I took that the wrong way, originally worried you were
saying the value of discard_alignment couldn't be trusted.
prev parent reply other threads:[~2019-01-11 2:47 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
2019-01-11 2:47 ` james harvey [this message]
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='CA+X5Wn5LH149=sDXqL-O9j1qMjNUVTrucnfyGyN_=ujPOun2dQ@mail.gmail.com' \
--to=jamespharvey20@gmail.com \
--cc=jaxboe@fusionio.com \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.petersen@oracle.com \
/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.