--- Jeremy Katz <katzj(a)redhat.com> wrote:
Realistically, something like a --filesystem is the wrong approach.
squashfs is "right", then we should go down that route. Trying to
encode the differences between squashfs and zisofs is the path to
I respectfully disagree. An alternate suggestion would be to standardize on
filesystem images living on the iso. I.e. currently the choice is between a
'native' zisofs, and a squashfs image. If say, the choice was between a zisofs
image, a squashfs image, and an ext2 image, then the user would have a nice set
of options. If in addition you go down the route of unionfs rather than
readonly-root and bindmounting, then you have a solution in which even selinux
is an option.
I think you might have mentioned a problem with ext2 and cdrom 2k block size.
I strongly suspect that if that is a problem, it's not a problem when you put
the ext2 filesystem on an image file which lives in an iso.
Having a case/switch statement use alternate tools to mk*fs the image, and then
having the initrd mount the right type of filesystem really isn't that ugly at
To evangelize unionfs one step further (and competely orthogonal to the rest of
this post), one could seperate the system image into two parts.
a) those parts that have been profiled as being used during boot and initial
b) the rest.
Then if you have seperate fs images for those parts, and store them on the
cdrom, you should get improved boot speed, because of less seek thrashing
during boot. For more bonus, you get mkisofs to put the boot files on the
outer tracks, to possibly get that extra 5%.
I'll go ahead and do a proof of concept on this if no one else is interested.
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around