Re: kern/48787

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

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

From: "Thomas Schmitt" <scdbackup%gmx.net@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/48787
Date: Thu, 22 May 2014 10:57:36 +0200

 > However, this will be a larger project than just
 > updating code in cd9660.
 
 I really try to keep it enclosed there.
 
 > The problem is that an extent (as you
 > indicate above) ist a "byte interval ... of the overall file".  What this
 > means is that you can have a file with a first extent of, say, 3 bytes
 > and a second one of 5 bytes
 
 I plan to throw a suitable error in this case.
 The existing examples in the code use EINVAL, which i deem
 somewhat misleading. Also there are som ESTALE which seem to
 stem from copied code that originally served for NFS.
 
 > The buffer cache in its current implementation doesn't support
 > this.kind of fragmentation.
 
 Yes. I could only spot a file-to-device address translation which
 is block-wise (512 bytes per block).
 cd9660_bmap.c : cd9660_bmap()
 
 I did not look yet, whether my host operating system would tolerate
 file sections which are not aligned to block size and in some file
 play a role as non-last filesection.
 (The relation between extent and file section is 1:1, between
  file section and iso_node it is m:n.)
 
 First i want to develop a solution and only then i want to know
 where others were smarter than me.
 
 
 Somewhat an obstacle are my pending PRs 48808 and 48815, which
 are currently the base of my development.
 (I will have to look for instructions for re-syncing my source
  with CVS without negative side effects.)
 
 
 The 64-bit ino_t of NetBSD is a heaven's gift.
 cd9660_vget_internal() needs to know the number of file sections
 while having only an ino_t as clue. And ISO 9660 implements the
 list of directory records as a block array in which each block
 holds an individual linked list. Fuzzy end, if you do not know
 the array end, which is stored far away from the array.
 My todo list has as solution:
     +++ Encode in ino_t:
         48 bits of byte address of first record (as is done already now)
         13 bits of file section count - 1.
                    Enough for filling the whole fs by 1 GiB pieces.
                    Possibly cd9660_vget_internal() should curb to a
                    much lower number.
                    count - 1 will keep numbers unchanged for single-extent
                    files. Count 0 is really impossible, not only illegal.
          3 bits are still unused.
 
 My assessment-and-plan text has 900 lines meanwhile.
 The emerging patch is at 786 lines.
 It is still not recognizing multiple extents but on the other
 hand it still works properly.
 Next point on my todo list is to develop a script that creates
 a challenging ISO image. Not only for multi-extent but also for
 regression tests with all (Rock Ridge) file types.
 
 Then i will dare to let cd9660 recognize multi-extent files
 and hope that it passes the tests.
 (It is not without risk. I had a bug which got the whole VM stuck
  just because it read undefined memory and maybe used the bad
  bit pattern as block address for reading.)