Re: kern/48808

["Thomas Schmitt" <scdbackup%gmx.net@localhost>]

The following reply was made to PR kern/48808; it has been noted by GNATS.

From: "Thomas Schmitt" <scdbackup%gmx.net@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/48808
Date: Wed, 14 May 2014 18:17:03 +0200

 I can now answer the question about partitioned devices, which
 are not cd but rather wd (XXX in cd9660_mount.h):
 
 Mounting of /dev/wdX? is indeed handled by cd9660_vfsops.c
 differently than with /dev/cdX?.
 
 A hard disk partition is used with its own block addressing
 which starts by 0.
 A cd "partition" is used with the block addressing of the
 base device /dev/cdXd and a superblock offset given by the
 cd "partition" start.
 
 I will have to clarify the man page.
 Not easy to explain ... would this text be understandable ?
 ------------------------------------------------------------------
   -s block_offset
      Read the superblock from a block address, which is computed by
      adding block_offset to the default superblock offset implied by
      the choice of the device file.  The block size is 2048 bytes.
 
      Optical drives /dev/cd* with unformatted media are handled
      differently than other storage partitions.  /dev/cd?d points to
      the start of the first and oldest logical track on the loaded
      medium. /dev/cd?a points to the last and youngest logical track.
      Nevertheless all block addressing is done relative to /dev/cd?d.
      Only the default offset is taken from /dev/cd?a, if that one is
      used. This matches the needs of ISO-9660 multisession on
      unformatted optical media.
 
      Formatted optical media and other kinds of storage partitions
      show no such default superblock offsets. Nevertheless they may
      bear several ISO-9660 sessions. Usually the superblock at offset
      0 leads to the youngest session.
 
      Other ISO-9660 sessions can be mounted by help of option -s with
      a block_offset which can be obtained from burn software for
      optical media. Among the /dev/cd* devices, use /dev/cd?d for this
      purpose.
 ------------------------------------------------------------------
 
 I have to stress that this situation is not created by my new option.
 It just adds a user-defined offset to the mess described above.
 
 ------------------------------------------------------------------
 My experiment:
 ------------------------------------------------------------------
 (Thanks to https://www.netbsd.org/docs/guide/en/chap-rmmedia.html)
 
 disklabel wd1 reports about my virtual MBR-formatted USB stick:
 
   #        size    offset     fstype [fsize bsize cpg/sgs]
    d:  10485760         0     unused      0     0        # ...
    e:   1606437        63 Linux Ext2      0     0        # ...
    f:   8867880   1606500 Linux Ext2      0     0        # ...
 
 Permissions are set quite liberally
   brw-r--r--  1 root  operator  0, 11 Feb  7 18:01 /dev/wd1d
   brw-rw-rw-  1 root  operator  0, 12 Feb  4 17:37 /dev/wd1e
   brw-rw-rw-  1 root  operator  0, 13 Feb  4 17:37 /dev/wd1f
 
 I write an ISO image into partition 1
 
   xorriso -outdev stdio:/dev/wd1e \
           -blank as_needed \
           -map libisofs-1.3.6 /libisofs-1.3.6
 
 xorriso can load the result and report about its files.
 Inspection with a hex dumper shows that the ISO 9660 Primary
 Volume Descriptor indeed is stored 63 * 512 + 16 * 2048 bytes
 after start of /dev/wd1d. All as expected for a partition
 with start at 512-block 63.
 
 So if partition /dev/wd1e can be mounted, then not with block
 addresses relative to /dev/wd1d (as would be done with with
 /dev/cd0a and /dev/cd0d). The offset of 63 * 512 would disalign
 all block addresses of the ISO which counts 2048-blocks.
 
 Well, mounting works fine:
   mount_cd9660 /dev/wd1e /mnt/iso
   ls -l /mnt/iso
   find /mnt/iso | less