Burning raw files/filesystems/archives/tar to disk/DVD/CD. Burning encrypted disks

What I mean here is that the disk will not contain any traditional disk FS like iso*, UDF etc.. but will contain a raw file at block level; the file that we'll be writing to the disk may be any file, like a tar archive with various compressions or squashfs image etc...

This can be done by cdrecord/wodim by simply placing the file instead of an iso image, or passing the file over stdout, e.g. -- 

cat test.squashfs | cdrecord speed=0  tsize=4617089843 driveropts=burnfree -

Here you've to set the tsize of the size of the squashfs image (in bytes), or alternatively you may simply specify the file as a command line argument -- 

cdrecord speed=0  tsize=4617089843 driveropts=burnfree test.squashfs

stdin is really useful for tar archives where you can directly stream the data while making the archive; here set the tsize to the size of the medium; in case the data is less than the specified tsize, it'll be padded with spaces; tar has no problems with this, but zip does, so don't burn zip archives.

To extract/mount -- 
unsquashfs /dev/sr0

mount /dev/sr0 ...

Speaking of mounting, udisk appears to recognize the squashfs volume on the DVD/CD and it works perfectly integrated with all DE... like with iso*/UDF filesystems.

For tar -- 

tar -xf /dev/sr0

It may give a warning that extra 0s toward the end has been ignored... which's perfectly fine.

The perfect FS or archive for the purpose -- 

squashfs – Its's detected perfectly by all DE; tsize can be easily figured out (writing the size of the FS image in bytes after figuring out it's size using ls, or using the input file at the squashfs image) but for the same reason you can't stream it to stdout, you've to make an intermediate large file. Also when burning, set the block size to largest possible, 1MB, cause without that seeking problems will occur, reducing read speeds and wearing out the drive. If you want compression with the FS you write to the disk, squashfs is the only option.


tar – Without various compressions (plane tar), can be streamed to stdout but you've to specify a large tsize (maximum of the disk maybe, a bit larger than the possible size of the archive); the extra 0s to the end don't matter, tar filters that out. On the downside, it can't be mounted natively as FS (not natively means you're using avfs, which I've discussed in the next post). If you use xz compression, the seek times to review a file will be too slow, cause lzma requires you to go through all the files which're placed previous to the file you wanna open, making it slow + it's single threaded. I've not tried gzip and bzip though.

Neither fuse-zip nor archivemount mounts the block device as archive. Only avfs works.

Using the same method, you can create a loop device (losetup) mapped to a encrypted block device via cryptsetup. Then you can write to this block device using mksquashfs (the file to be specified will be the block device -- mksquashfs works well this way). After you're done, remove the dm-crypt mapping, and optionally remove the loop device (or run sync); then burn the file (on which you created the loop device) to disk.

To read, cryptsetup on the DVD drive's block device and mount the resulting mapped block device.