26 Jul
2021
26 Jul
'21
6:34 a.m.
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