Re: Controlling the order of /dev/sdX devices?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



At Fri, 1 Apr 2011 15:04:04 +0100 CentOS mailing list <centos@xxxxxxxxxx> wrote:

> 
> I think that everyone lese lives in a far more ordered universe than i
> do.  My "problem" - no, wait - "challenge" is that i have zero control
> over the origin of incoming media on USB and eSATA.  Could be any brand
> of USB stick sold under the sun or HDDs formatted FAT32, NTFS, ext2/3.
> The only constants are things i directly control (sysdisk, RAID) -
> everything else is a crap-shoot.  Everyone else can use labels.

Nevermind the incoming (removable) media on USB and eSATA -- that is
not really your problem.  *Your* problem is only the system disk and
the 3ware RAID disk.  I understand that the sysdisk gets handed
properly early in the initrd (before udev's hotplug rule ruins your
day), this leaves the RAID disk. It presumable shows up with
*something* in .../device/vender that is specific to the 3ware
controller.  Since the (hardware) RAID disk is never going to be real
hardware disk (I presume you are not running the controller in JOBD
mode), it is going to have some 'made up' disk vendor / model,
generated by the RAID controller.  You should be able to use this
information in a SYSFS{device/vendor} check (eg
SYSFS{device/vendor}!="3warediskvendor") in your special hotplug rule
to force read-only mounting of "random" removable USB and eSATA disks
to force this rule to leave the RAID disk alone, no matter what it
shows up as.  OR you can have another rule to make the RAID disk show
up as *something* other than /dev/sdXX -- this is what I did with my
thumb drive, making it show up as /dev/thumb -- I also did something
similar with an old (now defunk) SCSI Zip and ORB2 drive.  There is
nother 'sacred' about the device files being /dev/sdXX, so long as the
major and minor device numbers are correct for the physical device.

> 
> I don't know about you but it "feels" like mounting a RAID array,
> possibly with an active mySQL database on it under udev is kind of
> disaster-prone.  I would much rather mount via fstab.
> 
> 
> - csawyer
> 
> -----Original Message-----
> From: centos-bounces@xxxxxxxxxx [mailto:centos-bounces@xxxxxxxxxx] On
> Behalf Of Brunner, Brian T.
> Sent: 01 April 2011 14:51
> To: CentOS mailing list
> Subject: Re:  Controlling the order of /dev/sdX devices?
> 
> centos-bounces@xxxxxxxxxx wrote:
> > Nope sir.  Assume never the same device twice and no control
> > over those devices, so UUID is out of the question.
> 
> UUID is out of the question where I have 3 drives (main and two backup)
> with "wear leveling" wherein ANY of the drives, put in /dev/sda's
> position, is the boot drive, the identical backup on /dev/sdb will get
> backed-up-to on a daily basis, and on a weekly basis the drive in
> /dev/sdb moves to /dev/sda's connector (becoming the boot drive),
> '/dev/sda' goes off-site, and the third moves to /dev/sdb's position
> (and gets backed-up-onto promptly.
> 
> LABEL also fails here.
> 
> > Yes, that's why you assign a LABEL to the device :) If the
> > same hard drive gets used on the same server, but on random
> > ports every time then the LABEL will still stay the same. I
> > have a similar setup where I mount about 40-odd USB drives to
> > a server on a regular basis. They each have their own mount
> > points in /mnt/usb-hdd/xxxxxxxxxx and irrespective of which
> > drive I connect to which USB port, or on which order, they
> > all get mounted where they're supposed to :)
> 
> This is excellent where each drive has distinct content.
> 
> Insert spiffy .sig here:
> Life is complex: it has both real and imaginary parts.
> 
> //me
> *******************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom
> they are addressed. If you have received this email in error please
> notify the system manager. This footnote also confirms that this
> email message has been swept for the presence of computer viruses.
> www.Hubbell.com - Hubbell Incorporated**
> 
> _______________________________________________
> CentOS mailing list
> CentOS@xxxxxxxxxx
> http://lists.centos.org/mailman/listinfo/centos
> _______________________________________________
> CentOS mailing list
> CentOS@xxxxxxxxxx
> http://lists.centos.org/mailman/listinfo/centos
> 
>                                                       

-- 
Robert Heller             -- 978-544-6933 / heller@xxxxxxxxxxxx
Deepwoods Software        -- http://www.deepsoft.com/
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments


                       
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos


[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux