Option to never do BLKRRPART ioctl in nvme format?

Nick Neumann nick at pcpartpicker.com
Tue Feb 7 13:12:33 PST 2023


On Mon, Jan 30, 2023 at 3:47 AM Daniel Wagner <dwagner at suse.de> wrote:
> I can't really say why BLKRRPART was added initially. The comment which was
> added later on
>
> /*
>  * If block size has been changed by the format
>  * command up there, we should notify it to
>  * kernel blkdev to update its own block size
>  * to the given one because blkdev will not
>  * update by itself without re-opening fd.
>  */
>
> indicates we don't need BLKRRPART necessary. I would like to understand first
> what's going on before dropping BLKRRPART.
>
> @Keith, do you happen to remember what's the reason for BLKRRPART?

Thanks much for the response. In my more meandering original email
(before I composed this one), Keith had said:
> There really is no need for user space to do the BLKRRPART ioctl
> anymore. The kernel takes care of the rescan automatically, so unless
> you've a really old kernel, we might be better off just removing the
> ioctl."

I had added a sleep delay of a few seconds as a workaround for the
intermittent error from BLKRRPART ioctl. It worked great, until today.
After hundreds of formats without issue, I got "failed to re-read
partition table" once again. So I'll resort to allowing the error code
if the error message is precisely that, and hopefully it can be
removed from nvme format sometime soon. :-)



More information about the Linux-nvme mailing list