27 Jul
2021
27 Jul
'21
3:02 p.m.
On 2021-07-26 9:34 a.m., Maciej W. Rozycki via cctalk wrote:
On Fri, 21 May 2021, Maciej W. Rozycki wrote:
Thanks for the analysis. I would have speculated that the difference
was in the SCSI CD-ROM driver for /dev/sr* devices since those are what
are used in modern Linux distributions. But your results quite clearly
show that's not the case. It also shows just how long ago the change
happened. Very interesting.
ISTR upstreaming some fixes to Linux UFS support
20+ years ago to address
this very problem (IIRC OSF/1 or Digital Unix CD-ROMs were also UFS, and I
had a need to access them under Linux for some reason) and with them in
place I thought the loop device hack was not needed anymore.
Perhaps my memory tricks me or something has since regressed though, e.g.
due to changes in the block layer, so I'll try to remember to see what's
happened here when I get to my Ultrix CDs when I'm in my remote lab next
time. It's not a feature that's used on a regular basis after all, so any
regression can be long-lived.
I remembered right. An old Linux 2.4.26 kernel binary mounts a UFS CD
here using the old IDE hardware driver just fine with no need for block
size translation via the loop device:
# mount -t ufs -o ro,ufstype=old /dev/hdc /mnt/cdrom
# mount | grep ufs
/dev/hdc on /mnt/cdrom type ufs (ro,ufstype=old)
# uname -a
Linux (none) 2.4.26 #8 SMP Sat Aug 14 21:00:06 CEST 2004 i586 unknown unknown GNU/Linux
#
Not anymore with Linux 2.6.18 or anything newer:
# mount -t ufs -o ro,ufstype=old /dev/hdc /mnt/cdrom
mount: wrong fs type, bad option, bad superblock on /dev/hdc,
or too many mounted file systems
# dmesg | tail -n 1
UFS: failed to set blocksize
# mount -t ufs -o loop,ro,ufstype=old /dev/hdc /mnt/cdrom
# mount | grep ufs
/dev/hdc on /mnt/cdrom type ufs (ro,loop=/dev/loop0,ufstype=old)
# uname -a
Linux (none) 2.6.18 #9 SMP Sun Nov 26 18:31:10 GMT 2017 i586 unknown unknown GNU/Linux
#
So we do have a regression here, sigh.