Re: Partition file proposal
Chris Rutter wrote:
>
> I have a fairly wacky proposal which concerns, mainly, boot-floppies on
> Linux/ARM. I've attached the proposal here; it should actually of generic
> relevance, but I'm only working on ARM for the time being. If anyone had
> any comments I'd be hugely hugely greatful. If not, skip the message.
> Thanks.
>
> ---<cut here>---
>
> A proposal for a partitioning file scheme
>
> v0.00 / 5th August 2000
>
> Chris Rutter <chris@armlinux.org>
>
> -- Rationale
>
> Many users of Linux/ARM, especially on Acorn hardware, find repartitioning a
> significant hurdle: the RISC OS tools are primitive (and don't include support
> for resizing), and unfriendly to the non-computer-literate.
>
> Furthermore, more experienced hackers may desire from time to time to have
> scratch partitions; perhaps to test a new distribution, or installation
> mechanism, or somesuch.
>
> There is a technique in Linux whereby the root of the filesystem can be
> re-mounted from one of its constituent files, viewed as a loopback device;
> for example (schematically):
>
> % mount /dev/hda1 -t adfs /
> % losetup /dev/loop0 /Linux/root
> % mount -o remount /dev/loop0 -t ext2 /
>
> There is no codified procedure for how the technique should be deployed in
> the kernel and user-land tools, however. This document proposes one.
>
Im not sure i really get what you mean, are your trying to figure out a
way to add loopback files to the kernel partition list
(/proc/partitions). It could be done entirely in userland though i
guess.
Sounds like a good idea, implementation might be difficult though.
> -- Requirements
>
> It's useful to be able to enumerate the partition files stored on any device
> without having to mount that device; for instance, in the Debian boot-floppies
> package, the segment of code which returns the list of partitions to the
> installer would have to fiddle about mounting every partition on every device
> in turn, searching through a list of probable locations for an `fstab' file,
> etc. This would be especially difficult in a call-iterative way.
>
> It would be better, I believe, to store a partition table adjoined to the
> one already on the disk: this way, there is a collected table that can be
> easily located, read and parsed. My suggestion, as the `Linux table' area
> of a FileCore disk reserves two sectors but occupies only one, would be to
> use the second sector of this table area.
>
> -- Table format
>
> I would propose the table be structured along these lines:
>
> typedef struct {
> uint32 magic;
> struct {
> uint32 size_in_sectors;
> unsigned char ms_dos_compatible_partition_type;
> unsigned char source_minor;
> char path_to_file[...];
> } partitions[...];
> }
>
> Where:
>
> * `source_minor' is the minor number of the partition within that device
> that contains the file referenced in `path_to_file';
>
> * `path_to_file' is zero-terminated, and represented as a string that can be
> concatanted to the mount path of `source_minor' -- e.g. `Linux/root';
>
> * each partition entry is aligned to 32 bits;
>
> * the table is terminated by a partition whose partition type is 0.
>
> Assuming an average length of `path_to_file' of 34 characters, this would
> give us room for eleven real partitions and a terminator in the 512-byte
> sector.
>
I dont understand the filetablespace very well, would this layout
interfere with other partitioning programs ?
> -- General syntax extension
>
> It would be helpful if there were a consistent way of referring to a partition
> file on a given device; I propose the use of a syntax thus:
>
> /dev/DEVICE:NUMBER
>
> where `DEVICE' would typically be an un-suffixed block device, and `NUMBER'
> the index into the partition file table of the wanted partition. For example
> `/dev/hda:4' to select the fifth partition file on the IDE primary master.
>
So if DEVICE = /dev/hda1:1 it would point to the first loop file on
hda1, this scheme should work with devfs as well.
> -- Kernel booting
>
> The kernel should check the `root' parameter it's passed for a `:'; if one is
> present it should decompose the string, and perform a mount-loop-remount
> operation.
>
> -- User-land utilities
>
> Utilities such as `mount' should be patched to recognise the syntax, so that
> people can create `/etc/fstab' entirely as normal, just specifying extended
> syntax device paths.
>
> (There is a question as to whether to leave `mount' to do all the parsing of
> the disk itself, or whether this should be performed in the kernel and exposed
> through a syscall interface.)
>
> When `mount' needs to access a native partition in order to losetup the
> partition file, it should:
>
> * check to see whether the native partition is already mounted, and if so
> simply use that path;
>
> * if not, mount it on `/.tmp-mount-UNID', where `UNID' is a unique ID
> determined in a similar fashion to tmpfile(), owned by root:root, and
> with minimal permissions (rw-------); perhaps even mounting it read only
> if the kernel will still write to bmapped files. These files should be
> reaped at boot time.
>
> Placing these temporary directories in the root obviates the dependency on
> any given filesystem layout and permissions thereof; specifically, avoiding
> `/tmp' prevents `tmpreaper' and other programs causing havoc.
>
> If a user wishes to have the source native partition mounted somewhere
> specific, all they need to do is to place an entry for it in `/etc/fstab'
> early on with their desired settings: all subsequent `mount' invocations
> should use that mounted directory.
>
> (One query: how will Linux respond to trying to re-mount an ADFS partition --
> perhaps in order to get at `/usr' -- when that was the same partition used at
> boot time in order to mount the root partition?)
>
> -- History
>
> v0.00 Initial revision
>
> --
Sounds like a good idea, something like this would make working with
loop files heaps better.
Glenn
Reply to: