Re: [woody,debinst] Interim filesystem

[bug1 <bug1@netconnect.com.au>]

Joey Hess wrote:
> I think this would require a minimum of 16 mb of disk space, and
> probably a bit more. Since with ramfs, disk space == memory, this
> would limit installations to systems with around 20-32 mb of memory.
> I don't think that's very acceptable.
> 
> I don't see how you could use loopfs without having first
> identified, partitioned, formated, and mounted a disk. If you're going
> to do that, then you might as well use my original proposal about
> this[1], which uses modular code to get the partitioning and so on done,
> downloads and extracts a base tarball, then chroots into it for the
> rest.
> 

How and Interim filesystem might work (as i see it)

There are a four possible alternate install paths at this stage.

1) Interim filesystem in memory.

2) Interim file on a local disk in its own partition.

3) Interim filesystem via network

4) Interim filesystem on an existing local filesystem via loopback
device

Case 1 : RAMDISK, RAMFS : This is likely to be the simplest and fastest
option, but would not work on lots of systems due to large memory
requirements.

Case 2 : TRADITIONAL : This is the traditional method used, it requires
partitioning prior to setting up any nonram filesystems, if this method
is taken there aren't really any advantages to an interim filesystem.
	This method placer large limitations on space for the initial boot
media which in turn limit the functionality of the install. 

Case 3 : NETWORK : The interim filesystem could be mounted from a remote
host e.g. NFS, (SMB?), it would probably require a small amount of
temporary write access somewhere.
	This remote interim filesystem could be used for multiple different
installs from different hosts, it would require the same complexity as
if the binary deb archive were sourced from the network.
	This method would be slow (depending on network speed) but would place
minimum requirements on local hardware (except network card) more space
on boot-media for net-tools, and there earlier configuration would add
extra complexity compared to a local install.

Case 4 : LOOP : By placing an extra filesystem layer between the interim
filesystem gains some independence over its local storage.
	The active loop filesystem is contained on multiple mirrored loop
filesystems on local writeable partitions. Mirroring can be done with
raid mode 1, this way if one of the loop files is destroyed it can be
rebuilt in another place.
	This method would allow us possible to totally repartition the local
storage, the only restriction is that it cant be done in one big hit,
which would mean that path *might* not be available to machines with one
drive, one partition, or if there is there is no room on mountable
partition for the loop files. 

	I have actually tried implementing something like this till today, ive
had some success, but also two OOPS's which i will try to track down
later.
	This is what i was doing, to do this you need a kernel with raid mode1
support,

	# Create two loop filesystems in some directory,
	# practically disk1 and disk2 should be different drives, at least
different partition.
	# for the test will use the same dir

	dd if=/dev/zero of=./loopfs1 bs=1k count=20000 
	dd if=/dev/zero of=./loopfs2 bs=1k count=20000 

	# mount the two files on loop devices
	losetup /dev/loop1 ./loopfs1
	losetup /dev/loop2 ./loopfs2

	# Create an etc/raidtab file containing
	raiddev			/dev/md0
	raid-level		1
	persistent-superblock	1   # or 0, shouldn't matter	
	chunk-size		16
	nr-raid-disks		2
	nr-spare-disks		0
	device			/dev/loop1
	raid-disk		0
	device			/dev/loop2
	raid-disk		1

	# make the loop files into raid devices
	mkraid /dev/md0

	# now treat it like a normal block device
	mkfs.ext2 /dev/md0
	mount -t ext2 /dev/md0 /mnt

	# Say the filesystem/partition containing the loop1 file had to be
destroyed
	# to enable repartitioning of that area of storage, 
	# i got an error filesystem is busy (or something like that) around
here, 
	# i had to recompile raidtools.
	raidsetfaulty /dev/md0 /dev/loop1
	raidhotremove /dev/md0 /dev/loop1  
	losetup -d /dev/loop1
	# the loopfs is now running in deraded mode from only loop2
	
	# we can now move ./loopfs1 to another location
	mv ./loopfs1 //newdir/

	# now reintegrate loopfs1 from its new location
	losetup /dev/loop1 /newdir/loopfs1
	raidhotadd /dev/md0 /dev/loop1

It did work for me once, but i got two oopses in other attempts, so it
still has problems.
It would require the installer scanning /proc/partitions and finding
filesystems it can write to, but repartitioning can then be done from
loopfs. 
	

Glenn