On Fri, 21 May 2021, Maciej W. Rozycki wrote:
> 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. I'll see what I can do about it,
but it'll have to wait a bit as I won't have local lab access for a while
and I dare not leaving a CD in the drive while I am away.
Maciej
