KHB: A Filesystems reading list

Posted Aug 22, 2006 18:27 UTC (Tue) by plougher (guest, #21620)
In reply to: KHB: A Filesystems reading list by nlucas
Parent article: KHB: A Filesystems reading list

>Couldn't we be using some variation of jffs2 for CD+-RW/DVD+-RW? Maybe >with the help of FUSE, as the kernel doesn't know how to write to the >CD/DVD?
>
>
Try squashfs - this is a compressed filesystem which is being used a lot for liveCDs. It also achieves better compression than JFFS2.

>
>It seems ideal for incremental backups, at least...

Squashfs is read-only, but it does support appending to the filesystem. This was added specifically to support incremental backups.

KHB: A Filesystems reading list

Posted Aug 22, 2006 23:49 UTC (Tue) by nlucas (guest, #33793) [Link] (2 responses)

Try squashfs - this is a compressed filesystem which is being used a lot for liveCDs. It also achieves better compression than JFFS2.

I really don't care about compression, but I suppose it doesn't hurt.

Squashfs is read-only, but it does support appending to the filesystem. This was added specifically to support incremental backups.

But how is this used on a DVD-RW?

1) You have a squashfs disk image and append to it, writing the final image to the CD/DVD when a certain size is reached?

2) You use a CD/DVD-RW (with UFS or whatever) and update a squashfs image file on the disk?

3) Other...

If it's 1) then it doesn't matter what filesystem is used. If it's 2), it's nice for incremental backups, but it will not allow you to take advantage of the fact that you can delete files on a -+RW disk (but good for -+R disks).

Hope it's 3)...

KHB: A Filesystems reading list

Posted Aug 23, 2006 1:25 UTC (Wed) by nlucas (guest, #33793) [Link]

s/UFS/UDF/

KHB: A Filesystems reading list

Posted Aug 24, 2006 18:27 UTC (Thu) by plougher (guest, #21620) [Link]

>If it's 1) then it doesn't matter what filesystem is used. If it's 2), >it's nice for incremental backups, but it will not allow you to take >advantage of the fact that you can delete files on a -+RW disk (but good >for -+R disks).

You could do 2) and store the Squashfs filesystem image inside a UFS/ISO9660 filesystem. If the UFS/ISO9660 filesystem was writable, then the Squashfs file could be updated and extended in place.

>Hope it's 3)...

I always write the Squashfs filesystem directly to the disk (not within a UFS/ISO9660 filesystem). Mounting is then done by mounting directly from the disk (i.e. mount -t squashfs /dev/hda /mnt). Appending to this can be done, but it requires the ability to update the superblock (block 0), and to re-write the directory structure. I've never tried to do this, and so don't know if it is possible.

Pure appending to the Squashfs filesystem (so no blocks in the original filesystem are touched) isn't possible, because of the need to update the superblock and directory structure (stored at the end of the filesystem). Extending Squashfs to do this isn't impossible, it requires Squashfs to append the new superblock (and changed metadata) to the end of the filesystem, and then scanning for any new superblocks on mounting - i.e. what log structured filesystems do.