[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Dual layer DVD



On Wed, Sep 08, 2004 at 12:25:29AM +0100, Steve McIntyre wrote:
> On Tue, Sep 07, 2004 at 07:04:44PM +0000, Joel Baker wrote:
> >
> >The simple answer would be to make sure that we have a reasonable selection
> >of two "disks" (for individual burns or dual-sided single-layered press
> >runs), and a way to make it easy for folks wanting to burn or press
> >single-sided dual-layer discs from those such that it requires no user
> >intervention to read the total (I don't know enough about the gritty
> >details of bridging filesystems across layers to know what this requires).
> 
> Dual-layer discs will need a single large filesystem that is simply
> split across the two layers. On data DVDs, the data is normally
> written to the lower layer from the inner edge to the outer edge, then
> swings back and starts again at the inner edge of the top layer. The
> filesystem is contiguous, though - the blocks logically continue
> uninterrupted across the layer split. A good plan is to try not to
> split a file across the split, purely for performance reasons.

I was hoping it was that simple, but it's dangerous to count on sanity in
this world...

> What I'd like us to do is create several image sizes for each arch:
> 
>   1 business card image (ISO, maybe jigdo too)
> 
>   1 netinst image (ISO, maybe jigdo too)
> 
>   13 or 14 650 MB CDs (jigdos on the main cdimage site, with some
>   mirrors carrying the full ISOs)
> 
>   2 4.7 GB DVDs (ditto)
> 
>   1 8.5 GB DL DVD image (probably jigdo only)
> 
> Jigdo means that we can do this without eating terabytes of disk space
> all over the world. To get the DL DVD images pressed will probably
> take extra preparation work - see my new dvdtape package for details.

This is more or less what I had in mind, other than some vague notion of
being able to auto-generate the 8.5 image from the pair of 4.7 images;
of course, jigdo might make that simple (no need to re-fetch most of the
pieces, only to fetch the filesystem layout bits and re-assemble them in
the correct combination - if it's that smart).
-- 
Joel Baker <fenton@debian.org>                                        ,''`.
Debian GNU/kNetBSD(i386) porter                                      : :' :
                                                                     `. `'
http://nienna.lightbearer.com/                                         `-

Attachment: signature.asc
Description: Digital signature


Reply to: