Andreas Dilger writes:
> Andries writes:
> > > I've implemented a patch for util-linux-2.11a
> > > which adds LABEL support to mkswap(8) and swapon/swapoff(8).
> >
> > But I would prefer a somewhat more ambitious approach.
> >
> > My first thought was: why label individual swap
Hi,
On Wed, Mar 14, 2001 at 02:11:57PM -0500, Lars Kellogg-Stedman wrote:
> > Put LABEL= in you fstab in place of the device name.
>
> Which is great, for filesystems that support labels. Unfortunately,
> this isn't universally available -- for instance, you cannot mount
> a swap partition by
Hi,
On Wed, Mar 14, 2001 at 02:11:57PM -0500, Lars Kellogg-Stedman wrote:
Put LABEL=label set with e2label in you fstab in place of the device name.
Which is great, for filesystems that support labels. Unfortunately,
this isn't universally available -- for instance, you cannot mount
a
Andreas Dilger writes:
Andries writes:
I've implemented a patch for util-linux-2.11a
which adds LABEL support to mkswap(8) and swapon/swapoff(8).
But I would prefer a somewhat more ambitious approach.
My first thought was: why label individual swap partitions?
I almost
In article <[EMAIL PROTECTED]> you wrote:
> The real problem is that our disks usually do not have a volume label.
> Outside of all file systems.
> The "signatures" that we rely on today are located in different places,
> so that a filesystem can have several valid signatures at the same time.
>
Andries writes:
> > I've implemented a patch for util-linux-2.11a
> > which adds LABEL support to mkswap(8) and swapon/swapoff(8).
>
> But I would prefer a somewhat more ambitious approach.
>
> My first thought was: why label individual swap partitions?
> I almost never want to distinguish swap
> I've implemented a patch for util-linux-2.11a
> which adds LABEL support to mkswap(8) and swapon/swapoff(8).
Yes, maybe a reasonable idea.
But I would prefer a somewhat more ambitious approach.
My first thought was: why label individual swap partitions?
I almost never want to distinguish
On Wed, 14 Mar 2001 12:34:06 -0700 (MST), Andreas Dilger wrote in LKML:
>Lars writes:
>> > Put LABEL= in you fstab in place of the device name.
>>
>> Which is great, for filesystems that support labels. Unfortunately,
>> this isn't universally available -- for instance, you cannot mount
>> a
On Wed, 14 Mar 2001, Richard B. Johnson wrote:
> This used to even be the way disks were located by the kernel
> drivers. Now, these are found in some "random" order.
>
> If whatever is causing the "random" order was fixed, put back like
> it used to be, etc., we wouldn't have these problems.
On Wed, 14 Mar 2001, Richard B. Johnson wrote:
This used to even be the way disks were located by the kernel
drivers. Now, these are found in some "random" order.
If whatever is causing the "random" order was fixed, put back like
it used to be, etc., we wouldn't have these problems.
On Wed, 14 Mar 2001 12:34:06 -0700 (MST), Andreas Dilger wrote in LKML:
Lars writes:
Put LABEL=label set with e2label in you fstab in place of the device name.
Which is great, for filesystems that support labels. Unfortunately,
this isn't universally available -- for instance, you cannot
I've implemented a patch for util-linux-2.11a
which adds LABEL support to mkswap(8) and swapon/swapoff(8).
Yes, maybe a reasonable idea.
But I would prefer a somewhat more ambitious approach.
My first thought was: why label individual swap partitions?
I almost never want to distinguish swap
Andries writes:
I've implemented a patch for util-linux-2.11a
which adds LABEL support to mkswap(8) and swapon/swapoff(8).
But I would prefer a somewhat more ambitious approach.
My first thought was: why label individual swap partitions?
I almost never want to distinguish swap
In article [EMAIL PROTECTED] you wrote:
The real problem is that our disks usually do not have a volume label.
Outside of all file systems.
The "signatures" that we rely on today are located in different places,
so that a filesystem can have several valid signatures at the same time.
And we
Hi,
The solution is not to go down the path2inst road, that is full of
its own traps. You want volume labels via a volume manager (do lvm and raid
already do this?) and/or filesystem labels (see e2fslabel). This won't solve
all of the ills associated with device instance changes, but it will
On Wed, Mar 14, 2001 at 05:53:16PM -0800, Tim Wright wrote:
> Well, if it sounds useful, I can look into putting up the design documentation
> (yes, shock, horror, there is some :-). It's pretty thorough and covers most
> of the issues involved, and hence might be a good talking point, even if we
On Wed, Mar 14, 2001 at 10:15:26AM -0800, Greg KH wrote:
[My ramblings on device naming database deleted]
> This comes up a lot with regards to USB devices too. One of the
> usb-serial drivers (the edgeport driver) did something like this by
> looking at the topology of the USB bus and where a
On Wed, 14 Mar 2001, Christoph Hellwig wrote:
> In article <[EMAIL PROTECTED]> you
>wrote:
>
> > The problem:
>
> > drivers change their detection schemes; and changes in the kernel can
> > change the order in which devices are assigned names.
> >
> > For example, the DAC960(?) drivers changed
On Wed, Mar 14, 2001 at 02:11:57PM -0500, Lars Kellogg-Stedman wrote:
> > Put LABEL= in you fstab in place of the device name.
>
> Which is great, for filesystems that support labels. Unfortunately,
> this isn't universally available -- for instance, you cannot mount
> a swap partition by label
On Wed, 14 Mar 2001, Lars Kellogg-Stedman wrote:
> > Put LABEL= in you fstab in place of the device name.
>
> Which is great, for filesystems that support labels. Unfortunately,
> this isn't universally available -- for instance, you cannot mount
> a swap partition by label or uuid, so it is
Lars writes:
> > Put LABEL= in you fstab in place of the device name.
>
> Which is great, for filesystems that support labels. Unfortunately,
> this isn't universally available -- for instance, you cannot mount
> a swap partition by label or uuid, so it is not possible to completely
> isolate
Christoph writes:
> In article <[EMAIL PROTECTED]> you
>wrote:
> > drivers change their detection schemes; and changes in the kernel can
> > change the order in which devices are assigned names.
> >
> > For example, the DAC960(?) drivers changed their order of
> > detecting controllers, and I
> Put LABEL= in you fstab in place of the device name.
Which is great, for filesystems that support labels. Unfortunately,
this isn't universally available -- for instance, you cannot mount
a swap partition by label or uuid, so it is not possible to completely
isolate yourself from the problems
On Wed, 14 Mar 2001, Christoph Hellwig wrote:
> Put LABEL= in you fstab in place of the device name.
>
> Christoph
>
> P.S. UUID= work, too - but I prefer a human-readable label...
There are a lot of different devices besides disks, e.g. tape drives etc.
I seem to remember from the last
In article <[EMAIL PROTECTED]> you wrote:
> The problem:
> drivers change their detection schemes; and changes in the kernel can
> change the order in which devices are assigned names.
>
> For example, the DAC960(?) drivers changed their order of
> detecting controllers, and I did _not_ have
On Wed, Mar 14, 2001 at 08:27:10AM -0800, Tim Wright wrote:
> This would currently be massive overkill for Linux, but DYNIX/ptx avoids this
> problem entirely by keeping a device naming database. This became necessary
> when we added support for multi-path fibre-channel connected disks. Most
>
On Wed, Mar 14, 2001 at 10:36:40AM -0500, John Jasen wrote:
>
> The problem:
>
[ Device name slippage ]
>
> Possible solutions(?):
>
> Solaris uses an /etc/path_to_inst file, to keep track of device ordering,
> et al.
>
> Maybe we should consider something similar, where a physical device to
The problem:
drivers change their detection schemes; and changes in the kernel can
change the order in which devices are assigned names.
For example, the DAC960(?) drivers changed their order of
detecting controllers, and I did _not_ have fun, given that the machine in
question had about 40
David Balazic wrote:
>
> Nathan Walp wrote:
> >
> > David Balazic wrote:
> > >
> > > Nathan Walp ([EMAIL PROTECTED]) wrote :
> > >
> > > > Also, sometime between ac7 and ac18 (spring break kept me from testing
> > > > stuff inbetween), i assume during the new aic7xxx driver merge, the
> > > >
Nathan Walp wrote:
>
> David Balazic wrote:
> >
> > Nathan Walp ([EMAIL PROTECTED]) wrote :
> >
> > > Also, sometime between ac7 and ac18 (spring break kept me from testing
> > > stuff inbetween), i assume during the new aic7xxx driver merge, the
> > > order of detection got changed, and now the
Nathan Walp wrote:
David Balazic wrote:
Nathan Walp ([EMAIL PROTECTED]) wrote :
Also, sometime between ac7 and ac18 (spring break kept me from testing
stuff inbetween), i assume during the new aic7xxx driver merge, the
order of detection got changed, and now the ide-scsi virtual
On Wed, Mar 14, 2001 at 10:36:40AM -0500, John Jasen wrote:
The problem:
[ Device name slippage ]
Possible solutions(?):
Solaris uses an /etc/path_to_inst file, to keep track of device ordering,
et al.
Maybe we should consider something similar, where a physical device to
logical
On Wed, Mar 14, 2001 at 08:27:10AM -0800, Tim Wright wrote:
This would currently be massive overkill for Linux, but DYNIX/ptx avoids this
problem entirely by keeping a device naming database. This became necessary
when we added support for multi-path fibre-channel connected disks. Most
In article [EMAIL PROTECTED] you wrote:
The problem:
drivers change their detection schemes; and changes in the kernel can
change the order in which devices are assigned names.
For example, the DAC960(?) drivers changed their order of
detecting controllers, and I did _not_ have fun, given
On Wed, 14 Mar 2001, Christoph Hellwig wrote:
Put LABEL=label set with e2label in you fstab in place of the device name.
Christoph
P.S. UUID= work, too - but I prefer a human-readable label...
There are a lot of different devices besides disks, e.g. tape drives etc.
I seem to
Put LABEL=label set with e2label in you fstab in place of the device name.
Which is great, for filesystems that support labels. Unfortunately,
this isn't universally available -- for instance, you cannot mount
a swap partition by label or uuid, so it is not possible to completely
isolate
Christoph writes:
In article [EMAIL PROTECTED] you
wrote:
drivers change their detection schemes; and changes in the kernel can
change the order in which devices are assigned names.
For example, the DAC960(?) drivers changed their order of
detecting controllers, and I did _not_ have
Lars writes:
Put LABEL=label set with e2label in you fstab in place of the device name.
Which is great, for filesystems that support labels. Unfortunately,
this isn't universally available -- for instance, you cannot mount
a swap partition by label or uuid, so it is not possible to
On Wed, 14 Mar 2001, Lars Kellogg-Stedman wrote:
Put LABEL=label set with e2label in you fstab in place of the device name.
Which is great, for filesystems that support labels. Unfortunately,
this isn't universally available -- for instance, you cannot mount
a swap partition by label or
On Wed, Mar 14, 2001 at 02:11:57PM -0500, Lars Kellogg-Stedman wrote:
Put LABEL=label set with e2label in you fstab in place of the device name.
Which is great, for filesystems that support labels. Unfortunately,
this isn't universally available -- for instance, you cannot mount
a swap
On Wed, 14 Mar 2001, Christoph Hellwig wrote:
In article [EMAIL PROTECTED] you
wrote:
The problem:
drivers change their detection schemes; and changes in the kernel can
change the order in which devices are assigned names.
For example, the DAC960(?) drivers changed their order of
On Wed, Mar 14, 2001 at 10:15:26AM -0800, Greg KH wrote:
[My ramblings on device naming database deleted]
This comes up a lot with regards to USB devices too. One of the
usb-serial drivers (the edgeport driver) did something like this by
looking at the topology of the USB bus and where a
On Wed, Mar 14, 2001 at 05:53:16PM -0800, Tim Wright wrote:
Well, if it sounds useful, I can look into putting up the design documentation
(yes, shock, horror, there is some :-). It's pretty thorough and covers most
of the issues involved, and hence might be a good talking point, even if we
Hi,
The solution is not to go down the path2inst road, that is full of
its own traps. You want volume labels via a volume manager (do lvm and raid
already do this?) and/or filesystem labels (see e2fslabel). This won't solve
all of the ills associated with device instance changes, but it will
> David Balazic wrote:
> >
> > Nathan Walp ([EMAIL PROTECTED]) wrote :
> >
> > > Also, sometime between ac7 and ac18 (spring break kept me from testing
> > > stuff inbetween), i assume during the new aic7xxx driver merge, the
> > > order of detection got changed, and now the ide-scsi virtual
I've just noticed with 2.4.2-ac20 that /proc/sys/fs/binfmt_misc is no longer
being created. I have CONFIG_BINFMT_MISC=y in my .config. This was working
fine in 2.4.3-pre4.
Wayne
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Michal Jaegermann wrote:
>
> On Tue, Mar 13, 2001 at 04:36:18AM +, Alan Cox wrote:
> ...
> >
> > 2.4.2-ac20
> ...
> > o Fix Alpha build (Jeff Garzik)
>
> Now I see (at least on Alpha) a constant wailing:
>
> /linux-2.4.2ac/include/linux/binfmts.h:45:
On Tue, Mar 13, 2001 at 04:36:18AM +, Alan Cox wrote:
...
>
> 2.4.2-ac20
...
> o Fix Alpha build (Jeff Garzik)
Now I see (at least on Alpha) a constant wailing:
/linux-2.4.2ac/include/linux/binfmts.h:45: warning: `struct
mm_struct' declared inside
On Tue, Mar 13, 2001 at 02:24:54PM -0500, Nathan Walp wrote:
> David Balazic wrote:
> >
> > SCSI adapters are enumerated randomly(*) , relying on certain numbering
> > will get you into trouble, sooner or later.
> > There is no commonly accepted solution, AFAIK.
> > The same thing can happent to
David Balazic wrote:
>
> Nathan Walp ([EMAIL PROTECTED]) wrote :
>
> > Also, sometime between ac7 and ac18 (spring break kept me from testing
> > stuff inbetween), i assume during the new aic7xxx driver merge, the
> > order of detection got changed, and now the ide-scsi virtual host is
> >
Nathan Walp ([EMAIL PROTECTED]) wrote :
> Also, sometime between ac7 and ac18 (spring break kept me from testing
> stuff inbetween), i assume during the new aic7xxx driver merge, the
> order of detection got changed, and now the ide-scsi virtual host is
> host0, and my 29160N is host1. Is
Nathan Walp ([EMAIL PROTECTED]) wrote :
Also, sometime between ac7 and ac18 (spring break kept me from testing
stuff inbetween), i assume during the new aic7xxx driver merge, the
order of detection got changed, and now the ide-scsi virtual host is
host0, and my 29160N is host1. Is this on
David Balazic wrote:
Nathan Walp ([EMAIL PROTECTED]) wrote :
Also, sometime between ac7 and ac18 (spring break kept me from testing
stuff inbetween), i assume during the new aic7xxx driver merge, the
order of detection got changed, and now the ide-scsi virtual host is
host0, and my
On Tue, Mar 13, 2001 at 02:24:54PM -0500, Nathan Walp wrote:
David Balazic wrote:
SCSI adapters are enumerated randomly(*) , relying on certain numbering
will get you into trouble, sooner or later.
There is no commonly accepted solution, AFAIK.
The same thing can happent to disk
On Tue, Mar 13, 2001 at 04:36:18AM +, Alan Cox wrote:
...
2.4.2-ac20
...
o Fix Alpha build (Jeff Garzik)
Now I see (at least on Alpha) a constant wailing:
/linux-2.4.2ac/include/linux/binfmts.h:45: warning: `struct
mm_struct' declared inside
Michal Jaegermann wrote:
On Tue, Mar 13, 2001 at 04:36:18AM +, Alan Cox wrote:
...
2.4.2-ac20
...
o Fix Alpha build (Jeff Garzik)
Now I see (at least on Alpha) a constant wailing:
/linux-2.4.2ac/include/linux/binfmts.h:45: warning:
I've just noticed with 2.4.2-ac20 that /proc/sys/fs/binfmt_misc is no longer
being created. I have CONFIG_BINFMT_MISC=y in my .config. This was working
fine in 2.4.3-pre4.
Wayne
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
David Balazic wrote:
Nathan Walp ([EMAIL PROTECTED]) wrote :
Also, sometime between ac7 and ac18 (spring break kept me from testing
stuff inbetween), i assume during the new aic7xxx driver merge, the
order of detection got changed, and now the ide-scsi virtual host is
host0,
Alan Cox wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/alan/3.4/
>
> Intermediate diffs are available from
>
> http://www.bzimage.org
>
> (Note that the cmsfs port to 2.4 is a work in progress)
>
> Its now 2767631 bytes .gz but a fair
Alan Cox wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/3.4/
Intermediate diffs are available from
http://www.bzimage.org
(Note that the cmsfs port to 2.4 is a work in progress)
Its now 2767631 bytes .gz but a fair amount of
60 matches
Mail list logo