opensuse
[Arriba] [Todas las Listas]

Re: [opensuse] Mío 3rd harddisk ha cambiado a /sdk

To: opensuse@xxxxxxxxxxxx
Subject: Re: [opensuse] Mío 3rd harddisk ha cambiado a /sdk
From: "Brian K. White" <brian@xxxxxxxxx>
Date: Wed, 14 Sep 2011 14:06:19 -0400
Delivered-to: opensuse@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 14 Sep 2011 14:07:42 -0400
Envelope-to: traductor@xxxxxxxxxxx
In-reply-to: <4276536.OXbu3K8qkr@dhcppc12>
List-archive: <http://lists.opensuse.org/opensuse/>
List-help: <mailto:opensuse+help@opensuse.org>
List-owner: <mailto:opensuse+owner@opensuse.org>
List-post: <mailto:opensuse@opensuse.org>
List-subscribe: <mailto:opensuse+subscribe@opensuse.org>
List-unsubscribe: <mailto:opensuse+unsubscribe@opensuse.org>
Mailing-list: contact opensuse+help@xxxxxxxxxxxx; run by mlmmj
Organization: Aljex Software Inc.
References: <4276536.OXbu3K8qkr@dhcppc12>
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
En 9/14/2011 9:45 AM, Constante *Brouerius furgoneta *Nidek escribió:
no sabe lo que ha causado lo pero supongo me fue jugando con un *drdos *iso
disco. Al menos desde entonces, el /*sdc nombre de paseo ha sido cambiado a /*sdk

No los problemas más lejanos pero yo gustarían para regresarlo a /*sdc.
Cualesquier ideas?

hay no tal cosa como *reliably controlando el nombre de nodo del dispositivo más. Es *dynamically asignado en tiempo de detección, el cual significa en tiempo de bota y/o en cualquier *disconnect/*reconnect después de bota.

ID de uso o *UUID o ETIQUETA como vuestra referencia de punto del monte. Los días de *static el hardware que dirige es mucho tiempo ido.

Por qué lo fue *sdc para algunos periodo largo de tiempo y por qué lo es ahora *sdk incluso después de *rebooting? Cambiaste el orden en el cual este disco fue detectado.

Qué  que malo? Varias cosas posibles:

* modificaste *bios *settings cuál orden de bota alterada, o añadió/paseos sacados de la lista de bota.

* Modificaste *bios *settings que alteró detección o habilitando de paseos.

* Un ejemplo particular de encima, habilitaste *usb *legacy apoyo.

* Modificaste *bios *settings cuál alteró *pci/*pcie *irq *assignments.

* Añadiste o paseos físicos sacados.

* Un ejemplo particular de encima, tienes uno o más *usb paseos de pulgar *plugged en que tú no utilizado para tener *plugged dentro, o era anteriormente no tratado como paseo duro debido a *usb *legacy *settings o meramente el tipo de *formatting del pulgar conduce él.

* Añadiste/sacado *pci/*pcie tarjetas, o movido *pci/*pcie tarjetas alrededor a diferente *slots que eran dentro antes de que.

* Estoy suponiendo no tienes una tarjeta de redada del hardware que puede proporcionar cualquier número de discos virtuales "enteros individuales" justo por ir a es *bios y *carving fuera de *chunks del paseo físico espacía cualquier manera quieres. Pero que sería aún así otra manera una letra de paseo dada cambiará de uno chuta a próximo, o de un *disconnect/*reconnect a próximo.

* Estoy suponiendo no estás jugando con material elegante como *AoE o *iSCSI que puede añadir/sacar paseos virtuales *dynamically en cualquier tiempo, así posiblemente alterando orden de detección de otro *pre-existiendo paseos.

* Tienes más que uno externo *usb paseo, y cambiaste qué paseos eran *plugged dentro a qué *usb puertos.

* Cambiaste el orden en el cual el *kernel los conductores son cargados, quizás por sencillamente *upgrading/*downgrading *kernels, o por construir un nuevo *kernel con algunos conductores construidos-en *vs cuando módulos o vicio/*versa.

* Has no *rebooted nada pero meramente *unplugged/*replugged un paseo móvil, como un *sata paseo en un caliente-*swap *enclosure o un externo *esata/*firewire/*usb paseo. Cuándo haces esto la letra de paseo vieja no es *re-utilizado. En cambio es asignado el letra disponible más próxima. Si te no ha cambiado el hardware o *bios *settings _NADA_, entonces sencillamente *rebooting lo tendría que causar para conseguir *re-detectado en el mismo orden cuando siempre.

La respuesta real es que no puedes contar encima o pronosticar orden de detección del paseo más, y así que no puedes contar encima o pronosticar nombre de letra del paseo más. Es todo dinámico ahora. Incluso si lo parecido para ser compatible para 100 *reboots para 2 años, que es justo suerte y significa nada. El muy próximo *reboot podría ser todo diferente en respuesta a ninguno de las posibilidades por encima de y más que no incluso sé.

Si *rebooting no pone el paseo atrás a /*dev/*sdc , entonces entrar y modificar /*etc/*fstab para utilizar ID=*xxxx, *UUID=*xxxx, o VOLUMEN=*xxxx en vez de /*dev/*sd*

mirada en /*dev/disco/por-* para encontrar el valor para poner después del *equals señal.
*UUID Es la mayoría de robusto, *guaranteed único *etc, pero el ID es más humano *readable y justo sobre tan robusto para todos los propósitos prácticos. Cuándo leíste /*etc/*fstab (y si bota necesaria/*grub/carta.*lst Y /chutar/*grub/dispositivos.Mapa y /*etc/*grub.*conf),
ID=*scsi-*SAdaptec_3805_REDADA10_233F9F03-parte1
es mucho más significativo y útil a ti el lector humano que
*UUID=35316*b05-*e83un-4*fc2-9*dfe-*d4*f60*eb13*b07

Después de que que tú siempre justo órdenes de monte del asunto basadas en el monte señala no por el dispositivo o *id o *uuid, justo "monte /*usb3" y *fstab siempre lo encontrará por ID *wherever es *plugged dentro, cualquier cosa ordena el *kernel lo detectó, a toda costa de *disconnect/*re-conectar *re-*assignments.

ETIQUETA=*xxxx es incluso más humano *readable desde ti hace arriba del *xxxx para ser cualquier cosa quieres. Pero aquello es también exactamente por qué su un poco *unsafe, puedes fallar para ser prudente sobre hacer seguro utilizas nombres de volumen único algún tiempo. Aquello puede ser bueno o mal dependiendo en lo que necesitas. Si utilizas un nombre de volumen sencillo como "*freedos" y tener más que un disco con el mismo nombre de volumen, el sistema no puede decir el dos aparte y no puedes esperar o gustar los resultados. ID y *UUID nunca accidentalmente *collide o ser ambiguo como aquello. Por otro lado, el mismo potencial para ambigüedad podría ser utilizado expresamente. Si Quieres tener discos físicos diferentes para ser detectado la misma manera, te gusta podría tener 7 paseos diferentes del mismo tipo & de medida, el cual todos tienen ID diferente y *UUID, pero tú *formatted les toda la misma manera y les dio todo el mismo nombre de volumen "*BACKUP", podrías mantener un continuo rodando valor de semanas de *backups por *plugging sólo uno conduce dentro en un tiempo dado, pero un diferente uno cada día. Ningún asunto que del 7 te conduce tapón dentro, conseguirá detectado como "ETIQUETA=*backup" y conseguir montado al mismo /*media/*backup o *wherever quisiste, y así que puedes tener el mismo sencillo *backup trabajo cada día aparentemente escribiendo al mismo paseo, todavía realmente tienes un perpetuo 7 historia de día sin teniendo que hacer muy elegante *scripting.

--
*bkw
--
A *unsubscribe, *e-correo: *opensuse+unsubscribe@xxxxxxxxxxxx
Puesto que órdenes adicionales, *e-correo: *opensuse+help@xxxxxxxxxxxx


On 9/14/2011 9:45 AM, Constant Brouerius van Nidek wrote:
Do not know what has caused it but I assume it was me playing with a drdos iso
disk. At least since then, the /sdc drive name has been changed into /sdk

No further problems but I would like to return it to /sdc.
Any ideas?

There is no such thing as reliably controlling the device node name any more. It is dynamically assigned at detection time, which means at boot time and/or at any disconnect/reconnect after boot.

Use ID or UUID or LABEL as your mount point reference. the days of static hardware addressing are long gone.

Why was it sdc for some long period of time and why is it now sdk even after rebooting? You changed the order in which this disk was detected.

What does that mean? Several possible things:

* You modified bios settings which altered boot order, or added/removed drives from the boot list.

* You modified bios settings that altered detection or enabling of drives.

* A particular example of above, you enabled usb legacy support.

* You modified bios settings which altered pci/pcie irq assignments.

* You added or removed physical drives.

* A particular example of above, you have one or more usb thumb drives plugged in that you didn't used to have plugged in, or were previously not treated as a hard drive because of usb legacy settings or merely the type of formatting of the thumb drive itself.

* You added/removed pci/pcie cards, or moved pci/pcie cards around to different slots than they were in before.

* I'm assuming you don't have a hardware raid card which can provide any number of individual whole virtual "disks" just by going into it's bios and carving out chunks of the physical drive space any way you want. But that would be yet another way a given drive letter will change from one boot to next, or from one disconnect/reconnect to next.

* I'm assuming you're not playing with fancy stuff like AoE or iSCSI which can add/remove virtual drives dynamically at any time, thus possibly altering detection order of other pre-existing drives.

* You have more than one external usb drive, and you changed which drives were plugged in to which usb ports.

* You changed the order in which the kernel drivers are loaded, perhaps by simply upgrading/downgrading kernels, or by building a new kernel with some drivers built-in vs as modules or vice/versa.

* You haven't rebooted at all but merely unplugged/replugged a removable drive, like an sata drive in a hot-swap enclosure or an external esata/firewire/usb drive. When you do this the old drive letter is not re-used. instead it is assigned the next highest available letter. If you haven't changed the hardware or bios settings _AT ALL_, then simply rebooting should cause it to get re-detected in the same order as always.

The real answer is that you can't count on or predict drive detection order any more, and so you can't count on or predict drive letter name any more. It's all dynamic now. Even if it seemed to be consistent for 100 reboots for 2 years, that is just luck and means nothing. The very next reboot could be all different in response to any of the possibilities above and more that I don't even know.

If rebooting doesn't put the drive back to /dev/sdc , then go in and modify /etc/fstab to use ID=xxxx, UUID=xxxx, or VOLUME=xxxx instead of /dev/sd*

look in /dev/disk/by-* to find the value to put after the equals sign.
UUID is the most robust, guaranteed unique etc, but ID is more human readable and just about as robust for all practical purposes. When you read /etc/fstab (and if necessary /boot/grub/menu.lst and /boot/grub/devices.map and /etc/grub.conf),
ID=scsi-SAdaptec_3805_RAID10_233F9F03-part1
is a lot more meaningful and useful to you the human reader than
UUID=35316b05-e83a-4fc2-9dfe-d4f60eb13b07

After that you always just issue mount commands based on the mount point not by the device or id or uuid, just "mount /usb3" and fstab will always find it by ID wherever it's plugged in, whatever order the kernel detected it, regardless of disconnect/re-connect re-assignments.

LABEL=xxxx is even more human readable since you make up the xxxx to be whatever you want. But that's also exactly why its a little unsafe, you may fail to be careful about making sure you use unique volume names some time. That may be good or bad depending on what you need. If you use a simple volume name like "freedos" and have more than one disk with the same volume name, the system can't tell the two apart and you may not expect or like the results. ID and UUID will never accidentally collide or be ambiguous like that. On the other hand, the same potential for ambiguity could be used on purpose. If you WANT to have different physical disks to be detected the same way, like you could have 7 different drives of the same size & type, which will all have different ID's and UUID's, but you formatted them all the same way and gave them all the same volume name "BACKUP", you could maintain a continuous rolling weeks worth of backups by plugging only one drive in at a given time, but a different one each day. No matter which of the 7 drives you plug in, it will get detected as "LABEL=backup" and get mounted to the same /media/backup or wherever you wanted, and so you can have the same simple backup job every day seemingly writing to the same drive, yet really you have a perpetual 7 day history without having to do any fancy scripting.

--
bkw
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx


<Anterior por Tema] Tema Actual [Siguiente por Tema>