e2label takes as parms:
e2label <device name> <mount point>
What's useless about this is the association of device name and file
system label which is completely broken on SATA systems which do dynamic
assignment. e2label was a great idea, but did not go far enough to
abstract.
The Initial mount sequence using:
root=LABEL=/
should be modified to ignore the device assignment and dunamically scan
the drives for the root drive for initial bootup and DETECT
the device assignment rather then reverting to fixed device
assignments. As implemented it's pretty useless and is simply an aliasing
mechanism rather than solving the problem of the system being truly
dynamic.
On many systems, including the systems we ship, /dev/sda, /dev/sdb, and
/dev/sdc are dynamically created from 3Ware RAID arrays and the boot drive
on the SATA connectors of the motherboard tends to "float" (i.e. sdc can
move to sda or sdb between boots depending on how the arrays are
configured).
On a RAID 0 failure, by way of example, sdc becomes sdb and renders a
system unable to boot. The solution is to setup the initial scanning
for root to look for the "/" assignment from e2label, and dynamically
assign the /dev/sdX handle from this scanning.
Just a suggestion.
Jeff
On Tue, Mar 28, 2006 at 02:48:50PM -0700, Jeff V. Merkey wrote:
> e2label takes as parms:
>
> e2label <device name> <mount point>
Actually, it's label name, not "mount point". Some
people/distributions will use a label name of "/" for the root
filesystem, but that is purely a convention.
> What's useless about this is the association of device name and file
> system label which is completely broken on SATA systems which do dynamic
> assignment. e2label was a great idea, but did not go far enough to
> abstract.
It's not an association of device name and file system label. It is
an assignment of a filesystme label to a *filesystem*. The label is
actually stored in the ext3's superblock.
> The Initial mount sequence using:
>
> root=LABEL=/
>
> should be modified to ignore the device assignment and dunamically scan
> the drives for the root drive for initial bootup and DETECT
> the device assignment rather then reverting to fixed device
> assignments. As implemented it's pretty useless and is simply an aliasing
> mechanism rather than solving the problem of the system being truly
> dynamic.
You can do this, and on some distributions it does work that way; the
initial root device is actually an initrd, and the initrd will search
the drivers looking for the root drive. The blkid library, or the
blkid program, can be used provide that functionality (indeed the
mount program, when passed the argument "LABEL=/" can be compiled to
use the blkid library to do this searching).
So it does (or at least can) work this way already, but it's all
userspace stuff which is currently distro-specific. Which brings up
the question why you posted this on LKML....
- Ted
Theodore Ts'o wrote:
>On Tue, Mar 28, 2006 at 02:48:50PM -0700, Jeff V. Merkey wrote:
>
>
>>e2label takes as parms:
>>
>>e2label <device name> <mount point>
>>
>>
>
>Actually, it's label name, not "mount point". Some
>people/distributions will use a label name of "/" for the root
>filesystem, but that is purely a convention.
>
>
>
>>What's useless about this is the association of device name and file
>>system label which is completely broken on SATA systems which do dynamic
>>assignment. e2label was a great idea, but did not go far enough to
>>abstract.
>>
>>
>
>It's not an association of device name and file system label. It is
>an assignment of a filesystme label to a *filesystem*. The label is
>actually stored in the ext3's superblock.
>
>
>
>>The Initial mount sequence using:
>>
>>root=LABEL=/
>>
>>should be modified to ignore the device assignment and dunamically scan
>>the drives for the root drive for initial bootup and DETECT
>>the device assignment rather then reverting to fixed device
>>assignments. As implemented it's pretty useless and is simply an aliasing
>>mechanism rather than solving the problem of the system being truly
>>dynamic.
>>
>>
>
>You can do this, and on some distributions it does work that way; the
>initial root device is actually an initrd, and the initrd will search
>the drivers looking for the root drive. The blkid library, or the
>blkid program, can be used provide that functionality (indeed the
>mount program, when passed the argument "LABEL=/" can be compiled to
>use the blkid library to do this searching).
>
>So it does (or at least can) work this way already, but it's all
>userspace stuff which is currently distro-specific. Which brings up
>the question why you posted this on LKML....
>
> - Ted
>
>
Ted,
Thanks for clarifying. It does NOT work this way today, and the
detection of and translation of
LABEL=/ is passed in the kernel, so its a kernel issue. e2label also
originated here, and yes I know about where
its stored. I will modify the kernels we use to translate this into a
dynamic device handle. What
the rest of the world does is its problem. I was making a suggestion.
See subject = "suggestions".
Thanks for responding. This has been helpful.
Jeff
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
Jeff V. Merkey wrote:
> the detection of and translation of
> LABEL=/ is passed in the kernel, so its a kernel issue.
Incorrect. The kernel does zero 'LABEL=' processing. Read
init/do_mount*.c.
LABEL= is handled in initrd/initramfs normally.
Jeff
Jeff Garzik wrote:
> Jeff V. Merkey wrote:
>
>> the detection of and translation of
>> LABEL=/ is passed in the kernel, so its a kernel issue.
>
>
> Incorrect. The kernel does zero 'LABEL=' processing. Read
> init/do_mount*.c.
>
> LABEL= is handled in initrd/initramfs normally.
>
> Jeff
>
>
>
Jeff,
Thanks for verifying it is passed through the kernel to initrd, another
kernel component. It's also stored as EXT meta data
(also in the kernel). and retrieved from there. And its not accessible
from normal user space applications (except in raw mode).
One of these days you need to get down to Lindon for lunch. I'll even buy.
Jeff
On Tue, Mar 28, 2006 at 06:18:08PM -0700, Jeff V. Merkey wrote:
> Thanks for verifying it is passed through the kernel to initrd, another
> kernel component. It's also stored as EXT meta data
> (also in the kernel). and retrieved from there. And its not accessible
> from normal user space applications (except in raw mode).
No, the contents of initrd/initramfs is not shipped as part of a
standard kernel.org kernel. It is the responsibility of each
distribution to set up their initrd or initramfs initial boot scripts
themselves. One could argue that it would be better if there were a
standard set of initrd scripts (and udev binaries) paired with
specific kernel.org kernels and used by all distro's, but that's not
where we are right now.
The data is most certainly accessible from normal userspace
applications. All they have to do is link against blkid library;
indeed the kernel doesn't do any LABEL= or UUID= searching at all. By
design, it all supposed to be done in userspace.
- Ted
Theodore Ts'o wrote:
>On Tue, Mar 28, 2006 at 06:18:08PM -0700, Jeff V. Merkey wrote:
>
>
>>Thanks for verifying it is passed through the kernel to initrd, another
>>kernel component. It's also stored as EXT meta data
>>(also in the kernel). and retrieved from there. And its not accessible
>>from normal user space applications (except in raw mode).
>>
>>
>
>No, the contents of initrd/initramfs is not shipped as part of a
>standard kernel.org kernel. It is the responsibility of each
>distribution to set up their initrd or initramfs initial boot scripts
>themselves. One could argue that it would be better if there were a
>standard set of initrd scripts (and udev binaries) paired with
>specific kernel.org kernels and used by all distro's, but that's not
>where we are right now.
>
>
>
????????
>The data is most certainly accessible from normal userspace
>applications. All they have to do is link against blkid library;
>
>
All you need is a degree from MIT in advanced Fusion mechanics. :-)
>indeed the kernel doesn't do any LABEL= or UUID= searching at all. By
>design, it all supposed to be done in userspace.
>
>
?????????
Ted,
I give up on this one. I also agree a standardized initrd with built in
init is a great idea.
:-)
Jeff
> - Ted
>
>
>
Jeff V. Merkey wrote:
> Theodore Ts'o wrote:
>
>> On Tue, Mar 28, 2006 at 06:18:08PM -0700, Jeff V. Merkey wrote:
>>
>>
>>> Thanks for verifying it is passed through the kernel to initrd,
>>> another kernel component. It's also stored as EXT meta data
>>> (also in the kernel). and retrieved from there. And its not
>>> accessible from normal user space applications (except in raw mode).
>>>
>>
>> No, the contents of initrd/initramfs is not shipped as part of a
>> standard kernel.org kernel. It is the responsibility of each
>> distribution to set up their initrd or initramfs initial boot scripts
>> themselves. One could argue that it would be better if there were a
>> standard set of initrd scripts (and udev binaries) paired with
>> specific kernel.org kernels and used by all distro's, but that's not
>> where we are right now.
>>
>>
>>
> ????????
>
>> The data is most certainly accessible from normal userspace
>> applications. All they have to do is link against blkid library;
>>
> All you need is a degree from MIT in advanced Fusion mechanics. :-)
>
>> indeed the kernel doesn't do any LABEL= or UUID= searching at all. By
>> design, it all supposed to be done in userspace.
>>
>>
> ?????????
>
> Ted,
>
> I give up on this one. I also agree a standardized initrd with built in
> init is a great idea.
It's a great idea until you ask which init script will be used and
forced on all the other vendors. Or all the vendors, let's standardize
on my script, or your script, or Linus' script.
Better yet, let's leave it alone, because even if there were a script
with the kernel, it would not be a standard ir would only be a default.
All the vendors do their own thing because they feel it's best, and
that's not going to change (not probably should it).
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me