* [PATCH] libxfs: report device open errors during topology probing
@ 2026-08-27 11:28 Hans Holmberg
2026-08-31 7:10 ` Christoph Hellwig
0 siblings, 1 reply; 6+ messages in thread
From: Hans Holmberg @ 2026-08-27 11:28 UTC (permalink / raw)
To: linux-xfs; +Cc: aalbersh, cem, hch, djwong, Hans Holmberg
mkfs probes the device topology before libxfs_init opens the target.
If blkid cannot open the device, blkid_new_probe_from_filename returns
NULL and leaves the topology sector sizes initialized to zero. This
causes mkfs to report the misleading error "illegal sector size 0".
Report the underlying open error immediately so that permission
failures are diagnosed correctly. For example:
cannot probe device topology for device /dev/nvme1n1: Permission denied
Signed-off-by: Hans Holmberg <hans.holmberg@wdc.com>
---
libxfs/topology.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libxfs/topology.c b/libxfs/topology.c
index dc2aaa17..5571c9d8 100644
--- a/libxfs/topology.c
+++ b/libxfs/topology.c
@@ -230,8 +230,12 @@ blkid_get_topology(
blkid_probe pr;
pr = blkid_new_probe_from_filename(device);
- if (!pr)
- return;
+ if (!pr) {
+ fprintf(stderr,
+ _("cannot probe device topology for device %s: %s\n"),
+ device, strerror(errno));
+ exit(EXIT_FAILURE);
+ }
tp = blkid_probe_get_topology(pr);
if (!tp)
--
2.53.0
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] libxfs: report device open errors during topology probing
2026-08-27 11:28 [PATCH] libxfs: report device open errors during topology probing Hans Holmberg
@ 2026-08-31 7:10 ` Christoph Hellwig
2026-09-01 8:46 ` Hans Holmberg
0 siblings, 1 reply; 6+ messages in thread
From: Christoph Hellwig @ 2026-08-31 7:10 UTC (permalink / raw)
To: Hans Holmberg; +Cc: linux-xfs, aalbersh, cem, hch, djwong
On Thu, Aug 27, 2026 at 01:28:55PM +0200, Hans Holmberg wrote:
> mkfs probes the device topology before libxfs_init opens the target.
> If blkid cannot open the device, blkid_new_probe_from_filename returns
> NULL and leaves the topology sector sizes initialized to zero. This
> causes mkfs to report the misleading error "illegal sector size 0".
>
> Report the underlying open error immediately so that permission
> failures are diagnosed correctly. For example:
>
> cannot probe device topology for device /dev/nvme1n1: Permission denied
Did you also accidentally run mkfs as a regular users? :) That's how
I ran into this, but didn't get around fixing it.
>
> Signed-off-by: Hans Holmberg <hans.holmberg@wdc.com>
> ---
> libxfs/topology.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/libxfs/topology.c b/libxfs/topology.c
> index dc2aaa17..5571c9d8 100644
> --- a/libxfs/topology.c
> +++ b/libxfs/topology.c
> @@ -230,8 +230,12 @@ blkid_get_topology(
> blkid_probe pr;
>
> pr = blkid_new_probe_from_filename(device);
> - if (!pr)
> - return;
> + if (!pr) {
> + fprintf(stderr,
> + _("cannot probe device topology for device %s: %s\n"),
> + device, strerror(errno));
> + exit(EXIT_FAILURE);
> + }
I wonder if there are any valid failures from blkid_new_probe_from_filename
where we'd want to continue? Probably not as it doesn't really have an
obvious failure path, but so far we continue here. So the print is useful
for sure, but I wonder if failing here might cause regressions in some
really odd use case (containers without sysfs? Although we'd run into
trouble with that quickly in other places).
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] libxfs: report device open errors during topology probing
2026-08-31 7:10 ` Christoph Hellwig
@ 2026-09-01 8:46 ` Hans Holmberg
2026-09-02 5:59 ` Christoph Hellwig
0 siblings, 1 reply; 6+ messages in thread
From: Hans Holmberg @ 2026-09-01 8:46 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-xfs, aalbersh, cem, djwong
On 31/08/2026 09:10, Christoph Hellwig wrote:
> On Thu, Aug 27, 2026 at 01:28:55PM +0200, Hans Holmberg wrote:
>> mkfs probes the device topology before libxfs_init opens the target.
>> If blkid cannot open the device, blkid_new_probe_from_filename returns
>> NULL and leaves the topology sector sizes initialized to zero. This
>> causes mkfs to report the misleading error "illegal sector size 0".
>>
>> Report the underlying open error immediately so that permission
>> failures are diagnosed correctly. For example:
>>
>> cannot probe device topology for device /dev/nvme1n1: Permission denied
>
> Did you also accidentally run mkfs as a regular users? :) That's how
> I ran into this, but didn't get around fixing it.
Yeah, I do this all the time and became so annoyed with the wierd error
message i had to fix it :)
>
>>
>> Signed-off-by: Hans Holmberg <hans.holmberg@wdc.com>
>> ---
>> libxfs/topology.c | 8 ++++++--
>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/libxfs/topology.c b/libxfs/topology.c
>> index dc2aaa17..5571c9d8 100644
>> --- a/libxfs/topology.c
>> +++ b/libxfs/topology.c
>> @@ -230,8 +230,12 @@ blkid_get_topology(
>> blkid_probe pr;
>>
>> pr = blkid_new_probe_from_filename(device);
>> - if (!pr)
>> - return;
>> + if (!pr) {
>> + fprintf(stderr,
>> + _("cannot probe device topology for device %s: %s\n"),
>> + device, strerror(errno));
>> + exit(EXIT_FAILURE);
>> + }
>
> I wonder if there are any valid failures from blkid_new_probe_from_filename
> where we'd want to continue? Probably not as it doesn't really have an
> obvious failure path, but so far we continue here. So the print is useful
> for sure, but I wonder if failing here might cause regressions in some
> really odd use case (containers without sysfs? Although we'd run into
> trouble with that quickly in other places).
Yeah, it might be safer to just print the warning, and that would solve
my problem (no instructive error message),
On the other hand it's nice to fail early - but not if it causes regressions
of course.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] libxfs: report device open errors during topology probing
2026-09-01 8:46 ` Hans Holmberg
@ 2026-09-02 5:59 ` Christoph Hellwig
2026-09-02 16:20 ` Darrick J. Wong
0 siblings, 1 reply; 6+ messages in thread
From: Christoph Hellwig @ 2026-09-02 5:59 UTC (permalink / raw)
To: Hans Holmberg; +Cc: Christoph Hellwig, linux-xfs, aalbersh, cem, djwong
On Tue, Sep 01, 2026 at 10:46:27AM +0200, Hans Holmberg wrote:
> > I wonder if there are any valid failures from blkid_new_probe_from_filename
> > where we'd want to continue? Probably not as it doesn't really have an
> > obvious failure path, but so far we continue here. So the print is useful
> > for sure, but I wonder if failing here might cause regressions in some
> > really odd use case (containers without sysfs? Although we'd run into
> > trouble with that quickly in other places).
>
>
> Yeah, it might be safer to just print the warning, and that would solve
> my problem (no instructive error message),
>
> On the other hand it's nice to fail early - but not if it causes regressions
> of course.
Yeah, failing early is nice, but I'm a bit fearful we might break
existing (but really weird setups).
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] libxfs: report device open errors during topology probing
2026-09-02 5:59 ` Christoph Hellwig
@ 2026-09-02 16:20 ` Darrick J. Wong
2026-09-03 5:35 ` Christoph Hellwig
0 siblings, 1 reply; 6+ messages in thread
From: Darrick J. Wong @ 2026-09-02 16:20 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Hans Holmberg, linux-xfs, aalbersh, cem
On Wed, Sep 02, 2026 at 07:59:54AM +0200, Christoph Hellwig wrote:
> On Tue, Sep 01, 2026 at 10:46:27AM +0200, Hans Holmberg wrote:
> > > I wonder if there are any valid failures from blkid_new_probe_from_filename
> > > where we'd want to continue? Probably not as it doesn't really have an
> > > obvious failure path, but so far we continue here. So the print is useful
> > > for sure, but I wonder if failing here might cause regressions in some
> > > really odd use case (containers without sysfs? Although we'd run into
> > > trouble with that quickly in other places).
> >
> >
> > Yeah, it might be safer to just print the warning, and that would solve
> > my problem (no instructive error message),
> >
> > On the other hand it's nice to fail early - but not if it causes regressions
> > of course.
>
> Yeah, failing early is nice, but I'm a bit fearful we might break
> existing (but really weird setups).
AFAICT hidden sysfs doesn't seem to break libbkid's probing of devices:
# mount moo /sys/ -t tmpfs ; mkfs.xfs -f /dev/sda
meta-data=/dev/sda isize=512 agcount=4, agsize=644992 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=1, sparse=1, rmapbt=1
= reflink=1 bigtime=1 inobtcount=1 nrext64=1
= exchange=1 metadir=1
data = bsize=4096 blocks=2579968, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0, ftype=1, parent=1
log =internal log bsize=4096 blocks=16384, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
= rgcount=0 rgsize=268435456 extents
= zoned=0 start=0 reserved=0
Discarding blocks...Done.
--D
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] libxfs: report device open errors during topology probing
2026-09-02 16:20 ` Darrick J. Wong
@ 2026-09-03 5:35 ` Christoph Hellwig
0 siblings, 0 replies; 6+ messages in thread
From: Christoph Hellwig @ 2026-09-03 5:35 UTC (permalink / raw)
To: Darrick J. Wong
Cc: Christoph Hellwig, Hans Holmberg, linux-xfs, aalbersh, cem
On Wed, Sep 02, 2026 at 09:20:25AM -0700, Darrick J. Wong wrote:
> AFAICT hidden sysfs doesn't seem to break libbkid's probing of devices:
Great. So *knocking on wood*, let's go with Hans's patch:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-09-03 5:36 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-27 11:28 [PATCH] libxfs: report device open errors during topology probing Hans Holmberg
2026-08-31 7:10 ` Christoph Hellwig
2026-09-01 8:46 ` Hans Holmberg
2026-09-02 5:59 ` Christoph Hellwig
2026-09-02 16:20 ` Darrick J. Wong
2026-09-03 5:35 ` Christoph Hellwig
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox