[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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.


Reply to: