Re: Issues with lseek(2) on a block device

[Crystal Kolipe <kolipe.c%exoticsilicon.com@localhost>]

On Sat, Feb 24, 2024 at 10:54:56PM +0000, Taylor R Campbell wrote:
> > Date: Sat, 24 Feb 2024 16:21:42 -0500
> > From: Thor Lancelot Simon <tls%panix.com@localhost>
> > 
> > On Wed, Feb 21, 2024 at 09:20:55PM +0000, Taylor R Campbell wrote:
> > > I think this is a bug, and it would be great if stat(2) just returned
> > > the physical medium's size in st_size -- currently doing this reliably
> > > takes at least three different ioctls to handle all storage media, if
> > > I counted correctly in sbin/fsck/partutil.c's getdiskinfo.
> > 
> > I am not sure this can be done for all block devices.  Tapes have block
> > devices, and open-reel tape drives do not really know the length of the
> > loaded media, while on any other tape drive supporting compression, there
> > may really be no such size.
> 
> Sure, it's fine if it doesn't give an answer (or, returns st_size=0)
> for devices where there's no reasonable answer.
> 
> But for a medium which does have a definite size that is known up
> front, it should just be returned by stat(2) in st_size instead of
> requiring a dance of multiple different NetBSD-specific ioctls to
> guess at which one will work.

We need to be careful with the definition of "definite size".

In simple terms, we can think of examples such as:

A physical HDD has a fixed size(*), so stat should report that, whereas a tape
drive with removable media can potentially present different sizes so stat
should return zero or indicate that situation in some other way.

But in a world of virtual machines with block devices that are dynamically
re-sizable on the host, it becomes more difficult.  Consider such a device
which _could_ be resized but in practice almost never is:

If stat returns what it thinks it the current or stable size of the device and
userland software retrieves and stores that value for future use rather than
using it immediately, then bad things will likely happen if the real value
changes later on.

On the other hand, if stat returns zero for the device because it could
possibly change size, (even though it almost certainly won't), then the
userland code will not function in conjunction with that device even though it
otherwise could.

(*) Ignoring the fact that the drive firmware can often be configured to
clip the size and report a smaller disk than is physically present.

In most cases, unless we are talking about a low-level disk utility, if
userland code is trying to find out the size of a raw block device then it
seems like a design error.