From: Anthony Iliopoulos <ailiop@suse.com>
To: Karel Zak <kzak@redhat.com>
Cc: util-linux@vger.kernel.org
Subject: Re: [PATCH] libblkid: add dax capability detection in topology probing
Date: Wed, 6 May 2020 15:21:41 +0200 [thread overview]
Message-ID: <20200506132141.GZ1329@technoir> (raw)
In-Reply-To: <20200506130847.d2u66a2lsrp4pfah@ws.net.home>
On Wed, May 06, 2020 at 03:08:47PM +0200, Karel Zak wrote:
> On Tue, May 05, 2020 at 04:31:45PM +0200, Anthony Iliopoulos wrote:
> > The dax (direct access) blockdev capability is exposed via sysfs, add it
> > to the list of topology values to be obtained while probing.
> >
> > Expose blkid_topology_get_dax() symbol that programs can link against
> > for querying the capability.
>
> Do we have any use-case for this change?
>
> We maintain blkid_topology_* mostly for mkfs-like programs portability
> (years ago we had only ioctls, etc..). You can see that libblkid export
> only small subset topology stuff, so why we need DAX there? ;-)
The use-case is indeed mkfs. I am planning to submit a patch to xfsprogs
that warns if the blockdev is dax-capable but the default or specified
fs blocksize isn't matching the platform page size (in which case the fs
cannot be used/mounted with dax). This comes up with archs like ppc64
where the page size is larger than the default (usually 4K) fs blocksize.
I wanted to avoid parsing sysfs from xfsprogs, especially given that
libblkid is already leveraged there to obtain the topology, and I assume
it may be handy for e2fsprogs too, as ext4 (and any other fs that may
support dax in the future) is bound to the same restriction.
next prev parent reply other threads:[~2020-05-06 13:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-05 14:31 [PATCH] libblkid: add dax capability detection in topology probing Anthony Iliopoulos
2020-05-06 13:08 ` Karel Zak
2020-05-06 13:21 ` Anthony Iliopoulos [this message]
2020-05-06 13:29 ` Karel Zak
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=20200506132141.GZ1329@technoir \
--to=ailiop@suse.com \
--cc=kzak@redhat.com \
--cc=util-linux@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox