Re: Issues with lseek(2) on a block device
On Sun, 25 Feb 2024 07:21:07 -0300 Crystal Kolipe wrote: > 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. There are many valid reason why applications may want to work with block or raw devices directly. A design error is to place artificial barriers which stop people from doing useful things with those devices. The whole idea of Unix was "everything is a file" and the sooner people get rid of magic ioctls the better.
Re: Issues with lseek(2) on a block device
> On Feb 25, 2024, at 12:29 AM, Robert Elz wrote: > > ps: as a semi-related anecdote, the first system I ever personally > installed any unix version onto (way back in the mid 70's) booted from > a reel to reel (1/2" I think) tape - and by booted, I mean ran with its > filesystems (or filesystem, everything was in one) on the tape (read only, > naturally). HP-UX install media on QIC-24 back in the HP-UX 7/8/9 days (earliest I have experience with) was also mounted as the file system. It’s quite a trip to see (well, hear, anyway) a tape drive get randomly-accessed like that. And, yah, it’s not fast. -- thorpej
Re: Issues with lseek(2) on a block device
On Sat, Feb 24, 2024 at 10:54:56PM +, Taylor R Campbell wrote: > > Date: Sat, 24 Feb 2024 16:21:42 -0500 > > From: Thor Lancelot Simon > > > > On Wed, Feb 21, 2024 at 09:20:55PM +, 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.
Re: Issues with lseek(2) on a block device
On Sat, 24 Feb 2024 16:28:28 -0500 Thor Lancelot Simon wrote: > On Thu, Feb 22, 2024 at 12:08:14PM +, Sad Clouds wrote: > > Hello, thanks to everyone who responded with their suggestions. Using > > various non-portable ioctls I can device size on most platforms, for > > both block and raw devices. > > > > This is more convoluted than a single lseek() call, but it is what it > > is. If anyone wants to do something similar, then the following example > > can give you a good start. > > Probably not a good idea to start with lseek() because if you _do_ > encounter a tape device, seeking to SEEK_END could take you an extremely > long time. > > Thor Hello, good point, however the software I'm developing is only meant to work with storage devices like disks, capable of random I/O. If someone decides to point it at the tape device, they get what they deserve :-)
Re: Issues with lseek(2) on a block device
Date:Sun, 25 Feb 2024 04:16:03 - (UTC) From:mlel...@serpens.de (Michael van Elst) Message-ID: | lseek() doesn't move the tape. But the open() or close() may trigger | tape operations like loading or winding. Special files are special. The issue is more the return value from lseek() - POSIX requires that lseek(fd, 0, SEEK_END) return the "size of the file" on any device which supports seeking (ie: not ttys, pipes, etc). A tape that supports seeking would be one of those, so somehow, lseek() as it is worded now, would be required to return "the size of the file" whatever that actually means for a tape. I have submitted a bug report (just earlier today) to get that fixed, but it will be some time before anything happens (it is too late now for the next version of the standard, which is currently in its final stages). kre ps: as a semi-related anecdote, the first system I ever personally installed any unix version onto (way back in the mid 70's) booted from a reel to reel (1/2" I think) tape - and by booted, I mean ran with its filesystems (or filesystem, everything was in one) on the tape (read only, naturally). It wasn't fast, but it worked...It worked even better once the filesystem was copied to a disc! (The issue was that, at the time, there was no available unix code that allowed booting from a disc, or not one of the kind that we had - whereas the hardware made booting from a tape absolutely trivial. All in the days before any kind of intelligent firmware console was available - booting required entering the boot program to ram via a front panel - "put X in location Y" ...)
