FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 09-30-2011, 07:36 PM
Bob Hoffman
 
Default add on sata card relabeling drives, installation

Well, first thing is I got lucky and not bought all the same drives. If
I had all the same I would never have known I put my OS on the two
drives added with the new sata card, something I DID NOT want to do.

If they were all 1 tb drives, it would have been a disaster to me.
Luckily I set up P0-P2 drives with my 500gb and saw the issue immediately.


Below is the issue I am talking about. The system ignores the sda/sdb
etc labeling to use UUID and things like hd0, hd1...
Yet mdstat shows you the drives in the useless labeling way...sda sdab

---------------------------
lamar owen wrote
There seem to be enough differences in the md scheme of 5.x and 6.x to
discourage disk interchange among the two in mdraid cases. Having said
that, I have an EL6.1 (upstream EL) machine with this:
[root at www ~]# cat /proc/mdstat
Personalities : [raid1]
md127 : active raid1 sdae1[0] sdaf1[1]
732570841 blocks super 1.2 [2/2] [UU]
-----------------------------

taking out a dead drive and adding a new one negates a real ability to
re-label them as you want since the new drive would have a different
UUID/serial, etc..and screw up any label system you might have done.


That mdstat is not the only monitoring software that pays attention to
the 'useless' labels like sda sdb sdc, etc...

and that leads to my fear of not getting accurate reports on problems
with drives or partitions...

(in my case I have 8 drives with 2 raid1 arrays made up of 3 drives
each, each one having a hot spare....and then a few drives as backups)

I am going to just leave it alone, but I feel their is something missing
in the whole theory...
if the labels sda, sdb, etc mean nothing to the system admin, then why
are they used in monitoring software...and worse, why are they the only
drive identification listed in the installer???

And the disk manager, graphical one, in centos 6 does not list the UUID,
it calls it 'worldwide ID'.


By forcing the use of UUID it makes monitoring impossible. If your
scripts use the UUID, then you must know the UUID and add them manually.
If you change out a drive, your script now fails to pick up the new
UUID....very annoying.

I am sure it is needed, but I still see UDEV using unchanging labeling
(things I would use to add grub on a drive) like 'HD0,HD1, etc.

why even use the labels, just use HD1, HD2 and the UUID and let it be.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 09-30-2011, 08:20 PM
Lamar Owen
 
Default add on sata card relabeling drives, installation

On Friday, September 30, 2011 03:36:50 PM Bob Hoffman wrote:
> Below is the issue I am talking about. The system ignores the sda/sdb
> etc labeling to use UUID and things like hd0, hd1...
> Yet mdstat shows you the drives in the useless labeling way...sda sdab
...

Useless? Those names are what the currently running kernel sees, and thus correspond to the current devices. You then have to do a little more digging with other tools, but that is what it is. The output from a cat of /proc/mdstat is raw data, and is more useful for rebuild status than anything else.

> taking out a dead drive and adding a new one negates a real ability to
> re-label them as you want since the new drive would have a different
> UUID/serial, etc..and screw up any label system you might have done.

For software RAID, yes. It makes it a challenge keeping up with what device is what. However, palimpsest (the GNOME Disk Utility included in EL 6) shows more detail about RAID components; also, if you check the drive itself there is a link in the page to the array device (Go to array).

It's not quite as easy as using, say, EMC Unisphere to manage arrays, but it's not bad. EMC arrays show you on the array itself, using an amber LED, exactly which drive is faulted, and also lights the amber fault LED on the enclosure, and numbers the drives by backend bus number, enclosure number, and drive number, so that, say, drive 14 in enclosure 7 on bus 3 would be device 3_7_14 (zero origin on all these numbers). But when you can have up to 960 drives in a single array such 'luxuries' become necessities (960 drives in a CX4-960; we have a CX4-480 that only will allow 480 drives, currently populated with 230). I can't imagine managing 480 drives on a Linux box with the current device naming.

> That mdstat is not the only monitoring software that pays attention to
> the 'useless' labels like sda sdb sdc, etc...

/proc/mdstat? It's not monitoring software; it's a kernel API mounted on the /proc filesystem; those names can and will change if disk enumeration order changes. File a bug report with the kernel developers to see this changed.

> I am going to just leave it alone, but I feel their is something missing
> in the whole theory...
> if the labels sda, sdb, etc mean nothing to the system admin, then why
> are they used in monitoring software...and worse, why are they the only
> drive identification listed in the installer???

Hmm, are they? I'll have to do another install to double check, but I think the drive model numbers/types are listed, but it has been a little bit since I did the install (of my RHEL 6.1 box at least).

If you want the disks listed differently in the installer, the right thing to do is file a bug report upstream (with Red Hat, in other words) on bugzilla.redhat.com, as CentOS is 100% going to do what upstream does in this regard.

> And the disk manager, graphical one, in centos 6 does not list the UUID,
> it calls it 'worldwide ID'.

That's because it is the WWN in the case of fibre channel, and a unique ID otherwise. WWN is unique, for fibre channel. Fibre channel: the original serial-attached SCSI. And, well, FC is giving way to dual-attach SAS in the enterprise space; 2.5 inch enterprise SAS drives in the EMC VNX series, for instance.

I have found palimpsest (the EL6 'Disk Utility' in the Applications -> System Tools menu) to give a lot of good information in one very nice display. It doesn't yet deal well with LVM; for that you use system-config-lvm. But the serial number, the filesystem label, RAID components, etc all in one place. Also, for one of the controllers I have it shows which port on the card a particular disk is attached to.

While many around this list detest GUI's on servers, I'll be honest; this is one very handy and useful utility that works quite well using ssh tunnelled X. A similar text-mode interface tool would be super nice, but someone has to write it, it's not in there right now.

> I am sure it is needed, but I still see UDEV using unchanging labeling
> (things I would use to add grub on a drive) like 'HD0,HD1, etc.

The grub device names are the BIOS names; the grub hd0 should be the BIOS boot drive. I say 'should be' because I have had a mismatch there before. So in my example (where /boot is on /dev/sdag) it just so happens that /dev/sdag is grub's hd0, but once the kernel comes up and enumerates the disks what was first shall become last... (hmmm, seems like a quote from the world's most popular book...).

> why even use the labels, just use HD1, HD2 and the UUID and let it be.

The /dev/sdX names are older than udev. Historical, (or hysterical, depending upon your PoV). HD1, HD2, etc would be far worse.

In the general case with PC hardware this is where things stand. With general PC hardware it becomes the responsibility of the individual systems administrator to simply know the machine inside and out, and document the machine thoroughly.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 09-30-2011, 08:40 PM
John R Pierce
 
Default add on sata card relabeling drives, installation

On 09/30/11 12:27 PM, m.roth@5-cent.us wrote:
> Um, we just went from the 1TB drives to 3TB drives, so I only need four.
>

yes, but 12 2.5" 1TB drives take the same amount of space (1U), and are
capable of higher IO throughput due to being more spindles.

--
john r pierce N 37, W 122
santa cruz ca mid-left coast

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 09-30-2011, 08:49 PM
 
Default add on sata card relabeling drives, installation

John R Pierce wrote:
> On 09/30/11 12:27 PM, m.roth@5-cent.us wrote:
>> Um, we just went from the 1TB drives to 3TB drives, so I only need four.
>>
> yes, but 12 2.5" 1TB drives take the same amount of space (1U), and are
> capable of higher IO throughput due to being more spindles.

You missed what I originally said: I have a two-bay eSATA dock, like this
<http://www.bizrate.com/hard-drives/2095977853.html>. And it's only on one
channel. It's not a high priority, so it takes me the better part of a
week to do the backups *shrug*, it also doesn't strain the network, esp.
when some folks are moving *large* amounts of data (we do actual
scientific computing here). Network lag would be very much of a bad thing.

mark

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 09-30-2011, 10:45 PM
Les Mikesell
 
Default add on sata card relabeling drives, installation

On Fri, Sep 30, 2011 at 11:57 AM, Lamar Owen <lowen@pari.edu> wrote:
>
> But 'breakage' and 'bugginess' are not synonyms; something can be broken for a corner case but not be a bug in the general sense. *Is the current filesystem mounting standard broken? *In certain use cases most certainly. *Is the current filesystem mounting standard buggy? *For the targeted use cases probably not.

I think the first incarnation of the 'labels in fstab' that I saw
would have died a horrible death if you did a dual boot install with 2
copies of it, something that should have been planned as a normal use
case. That might have been a fedora version though, and I'm not sure
what happens in that case now.

>*After all, upstream developers and CentOS builders all operate within finite resource limits; it takes infinite resources to reach perfection.

But there are only 2 hard problems in computer science: naming things,
cache invalidation, and off-by-one errors. (Hmmm, can't find the
right attribution for that now).

--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 10-01-2011, 04:56 AM
Cliff Pratt
 
Default add on sata card relabeling drives, installation

On Sat, Oct 1, 2011 at 5:03 AM, Lamar Owen <lowen@pari.edu> wrote:
>
> UUID is, IMHO at least, the worst of all worlds due to the length
> and the user-unfriendliness of it all (it's been the Ubuntu default
> for a while, though!). *It is guaranteed unique (until you use
> complete clones), but is the most difficult to change and use.
>
Surely it is a single command? Two if you have to generate the UUID.
On my home machine I cloned my boot drive, then set the UUID of the
second drive with:

prompt> uuidgen
then cut and paste into
prompt> tune2fs /dev/sdb1 -U c491d94e-7004-4b08-9993-4c9a7a25b6b1
and check it with
prompt> blkid

Cheers,

Cliff
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 10-01-2011, 04:24 PM
Lamar Owen
 
Default add on sata card relabeling drives, installation

On Saturday, October 01, 2011 12:56:46 AM Cliff Pratt wrote:
> prompt> tune2fs /dev/sdb1 -U c491d94e-7004-4b08-9993-4c9a7a25b6b1

As the saying goes, try typing that fast ten times.... and see how many times the UUID ends up being fat-fignered.

Unless the UUID contains spellable words that use only the hex digits (like deadbeef, cafebabe, or similar). (you can find a list of 1196 hex words at http://nedbatchelder.com/text/hexwords.html )

Mnemonics are essential for jogging the memory... oh, wait....

"Now, was that filesystem with the backup copy of that priceless one-in-a-lifetime video c491d94e-7004-4b08-9993-4c9a7a25b6b1 or was it bb6c2bb9-f01e-3135-a8de-9f885a7afdef or maybe it was f82ffa31-2587-3db8-970a-36e54e72621b... oh, I don't remember!"

But I guess if you physically label the disk with the partitioning and the UUID's of each filesystem, it might be workable.

Too bad many, if not most, drive serial numbers are not spellable in hex....
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 10-01-2011, 11:37 PM
Cliff Pratt
 
Default add on sata card relabeling drives, installation

On Sun, Oct 2, 2011 at 5:24 AM, Lamar Owen <lowen@pari.edu> wrote:
> On Saturday, October 01, 2011 12:56:46 AM Cliff Pratt wrote:
>> prompt> tune2fs /dev/sdb1 -U c491d94e-7004-4b08-9993-4c9a7a25b6b1
>
> As the saying goes, try typing that fast ten times.... and see how many
> times the UUID ends up being fat-fignered.
>
I said, in a bit that you snipped, cut-and-paste.
>
> Unless the UUID contains spellable words that use only the hex digits
> (like deadbeef, cafebabe, or similar). (you can find a list of 1196 hex
> words at http://nedbatchelder.com/text/hexwords.html )
>
> Mnemonics are essential for jogging the memory... oh, wait....
>
> "Now, was that filesystem with the backup copy of that priceless
> one-in-a-lifetime video c491d94e-7004-4b08-9993-4c9a7a25b6b1 or was
> it bb6c2bb9-f01e-3135-a8de-9f885a7afdef or maybe it was
> f82ffa31-2587-3db8-970a-36e54e72621b... oh, I don't remember!"
>
That's silly. The UUID is probably only of interest when the disk or
partition is being mounted. If it isn't mounted, mount it and *look*.
>
> But I guess if you physically label the disk with the partitioning and
> the UUID's of each filesystem, it might be workable.
>
> Too bad many, if not most, drive serial numbers are not spellable in hex....
>
Cheers,

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

Thread Tools




All times are GMT. The time now is 09:24 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org