* [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