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
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 l
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.
> A
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 swap
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 sw
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.
An
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 c
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 sp
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 t
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 no
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 yo
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
> 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 ro
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
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
> dev
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 dis
21 matches
Mail list logo