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 <[EMAIL PROTECTED]>
-- 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.
-- 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.
-- 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.
-- 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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
