Re: kern/48787

[Wolfgang Solfrank <Wolfgang%Solfrank.net@localhost>]

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

From: Wolfgang Solfrank <Wolfgang%Solfrank.net@localhost>
To: gnats-bugs%NetBSD.org@localhost, kern-bug-people%netbsd.org@localhost, 
 gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, 
scdbackup%gmx.net@localhost
Cc: 
Subject: Re: kern/48787
Date: Thu, 22 May 2014 01:23:28 +0200

 Hi,
 
 >   >  -rw-r--r--  1 dbus  dbus  4294965248 May  6 15:30 large_file
 >   >  -rw-r--r--  1 dbus  dbus  4294965248 May  6 15:30 large_file
 >
 >   This is a different bug. ISO 9660 level 3 allows to store files
 >   larger than 4 GiB - 1. This is done by several directory entries
 >   with the same name marking a byte interval ("extent") of the
 >   overall file.
 ...
 >   When i assessed the problem in FreeBSD 2 years ago, i noticed
 >   a 1:1 relation between iso_node and extent. It would have to
 >   become 1:n, or multi-extent files would have to be handled
 >   as reason for a well contained error. (Not easy to imagine how
 >   the latter shall work consistently.)
 >
 >   I plan to look for a solution.
 >   But that change will be a fat patch, i guess, because it will
 >   include an adjustment of the object relationship graph in cd9660.
 
 Be my guest.  However, this will be a larger project than just
 updating code in cd9660.  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 and so on (which looks absurd when
 you first look at it, but does make sense if you think about multi-
 session cds where you e.g. extend some logfile in a later session.)
 The buffer cache in its current implementation doesn't support
 this.kind of fragmentation.
 
 Ciao,
 Wolfgang
 -- 
 Wolfgang%Solfrank.net@localhost                                Wolfgang 
Solfrank