[PATCH] volume_id: volume_id_get_buffer with small FSes

[Alyssa Ross]

On Mon, May 16, 2022 at 05:36:16PM +0300, Lauri Kasanen wrote:
> On Mon, 16 May 2022 10:03:20 +0000
> Alyssa Ross <hi at alyssa.is> wrote:
>
> > On Mon, May 16, 2022 at 08:23:37AM +0300, Lauri Kasanen wrote:
> > > On Sun, 15 May 2022 17:18:47 +0000
> > > Alyssa Ross <hi at alyssa.is> wrote:
> > >
> > > > I tested both the cases mentioned in the comments — an empty floppy
> > > > drive, and an unused loop device.  Reading from an empty floppy drive
> > > > is ENXIO, and reading from an unused loop device returns 0, so it
> > > > should be fine to drop the minimum length, and be happy with any read
> > > > as long as it returns at least one byte.
> > >
> > > > -		 * accesses. Rationale:
> > > > -		 * users complained of slow blkid due to empty floppy drives.
> > >
> > > But is it slow like the comment said? Ie. does this patch cause a 1-2s
> > > delay due to the floppy drive spinning up?
> >
> > How would it?  In the case of a floppy or loop device, the operations
> > that are happening are exactly the same.  Both before and after my
> > patch, it would try to seek or read, that would fail, and then it would
> > set id->error and return.
>
> If you mean that the code comment was wrong, please mention that in
> the commit message.

I do not mean that.  The previous check was one way of setting id->error
for floppy drives and loop devices, and this is a better way of doing
the same thing that doesn't also break small filesystems.

In any case, it has been pointed out to me that since commit
4fc5ec56f ("device matching against UUIDs: do not try floppies") (from
2009), floppy drives are skipped before this function is even called.
But that's orthogonal to the correctness of my patch.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20220516/b4cfccb3/attachment.asc>