Hi Redhat, I hate you

[The Linuxator]

"Hi Redhat, I hate you"

Hi n0cmonkey, I hate you and I don't need a reason for it 😛

 

[Nothinman]

Ok, maybe standard is the wrong word. Maybe I have to specify it as a historical standard. Tru64 is a fringe case anyhow.

IMO Tru64 is no more of a fringe case than any of the free BSDs or HP-UX, so why should one be given precedence over the other? And as I said, the device naming convention is more confusing than the use of labels. /dev/sd*, /dev/hd*, /dev/wd*, /dev/dsk/c?t?d?s?, /dev/disk/dsk??.

Last I heard (recently, but in a dead tree formatted magazine) cifs wasn't done, and didn't cover all of the cases smbfs did so they were hesitant to consider smbfs as deprecated.

I don't know what features are missing, I've used cifs with Win2K and Samba and it works pretty well. The big thing is that smbfs doesn't support files >2G by default and cifs does.

Just putty in this case. It was set to one of the MANY ISO standards (I can find the one it was set to previously, if you're curious).

No need, I was just curious if it was a local terminal or remote. I've never had much fun with putty, UTF8 and things like ncurses either although I don't remember man pages showing up screwy.

 

[n0cmonkey]

Originally posted by: Nothinman

Ok, maybe standard is the wrong word. Maybe I have to specify it as a historical standard. Tru64 is a fringe case anyhow.

IMO Tru64 is no more of a fringe case than any of the free BSDs or HP-UX, so why should one be given precedence over the other?

Tru64 is a fringe case. Even Linux had a more historically accurate fstab in previous incarnations.

And as I said, the device naming convention is more confusing than the use of labels. /dev/sd*, /dev/hd*, /dev/wd*, /dev/dsk/c?t?d?s?, /dev/disk/dsk??.

Yes, it is more confusing. It's the odd man out. How do I tell which raid array a particular disk is on? I know that what appears to be sda is on the first array, but is my mysql data on that one?

I don't know what features are missing, I've used cifs with Win2K and Samba and it works pretty well. The big thing is that smbfs doesn't support files >2G by default and cifs does.

The short blurb I read about it didn't mention what wasn't working, just that it didn't support as many situations as smbfs does.

No need, I was just curious if it was a local terminal or remote. I've never had much fun with putty, UTF8 and things like ncurses either although I don't remember man pages showing up screwy.

I don't think I've tried it local, but I'll give it a shot later. If I remember. 😛

 

[xtknight]

I'm pretty sure my SUSE /etc/fstab file looks like that too. Somehow I managed to edit it by just putting 0s at the end when I had no idea what they did. 😕 But it worked, and my house hasn't burned down, so I guess whatever I put in there was fine.

 

[drag]

I don't know...

I know that device naming and numbering is something that is fundamentally broken on Linux machines.

It's based on a first come first serve setup. It's a huge problem with USB devices.. for instance If I plug a mouse in first then my tablet then my configurations have to go:
/dev/input/event1 == mouse
/dev/input/event2 == tablet.

When I plug my tablet in first It goes:
/dev/input/event1 == tablet
Then if I want to play a game with my joystick then that makes the mouse:
/dev/input/event4 == mouse

And then don't even ask what goes on when I unplug my keryboard or try to use my trackball.

So thats screwed.

Now tell me what happens now in my server when I have the onboard IDE and 2 identical PCI SATA cards? What happens if I need to rearrange the cards to plug in a new device? What happens when I add a 3rd PCI card and a couple more drives?
I have:
/dev/hda = onboard IDE
/dev/hda1 = 'software raid'
/dev/hdb = DVD burner
/dev/sda = PCI slot 2, Sata drive 1
/dev/sda1 = 'software raid'
/dev/sda2 = /boot
/dev/sdb = PCI slot 2, Sata drive 2
/dev/sdb1 = 'software raid'
/dev/sdb2 = swap
/dev/sdc = PCI slot 4, Sata drive 1
/dev/sdc1 = 'software raid'
/dev/sdc2 = reserved
/dev/md0 = MD 'software raid 5'
/dev/mapper/picardVolumeGroup-<hostname><mountpointname>
(repeat 10 times)

It's a Xen system and I have 5 hosts configured to run on it.

Now tell me what happens If I plug a second drive into the second Sata to PCI adapter AND I add two more drives to a new PCI adapter on slot 3. Should I move the PCI adapters around to try to preserve the /dev/ names? Would that even work? What If I want to migrate the drives to a different machine?

The traditional numbering method works when you have a static machine, with local storage, and so on and so forth. Now you have machines were the storage is relative to how they are configured on the network with GFS and such.

Now that label stuff is news to me, and it's not going to solve my problems, but it seems like a step in the right direction. If you were aware of Redhat using fs labels to designate file systems, rather then specifying what paticular hardware device these file systems reside on, then it would of made more sense.

 

[Nothinman]

I know that device naming and numbering is something that is fundamentally broken on Linux machines.

Then how should it be done?

Pointing out something that you think is a problem is one thing, but finding a solution that actually works well is another.

 

[drag]

Originally posted by: Nothinman

I know that device naming and numbering is something that is fundamentally broken on Linux machines.

Then how should it be done?

Pointing out something that you think is a problem is one thing, but finding a solution that actually works well is another.

well.. DUH. 🙂

I know something is broken, but I don't know how to fix it. It's a fairly common occurance in my life, although it's less common for software then it used to be.

Basicly the problem is is that device names are determined by first come first serve. It depends on the order that the devices are detected. If you change something in the kernel or change how the hardware is arranged then probably you change the order that they are detected and thusly change the /dev name.

And if you have all your configuration based on /dev name then your screwed and things break.

For the device naming for USB devices you can now name them in your X.org config by part of of their USB identity strings that they send to the computer.

Instead of going:

Driver "mouse"
Option "device" "/dev/input/mouse0"

I can go:

Driver "evdev"
Option "name" "Logitech Optical USB Mouse"

Also you can now refer to devices by their USB number and various other identifaction strings. You can find the names and such for devices by looking at /proc/bus/input/devices

Otherwise /sysfs and udev (and hal I suppose) are the 'real' solution to this problem that Linux/Freedesktop.org people have devised. It's now nearly possible to use udev to set /dev/ names that remain consistant irregardless of this or that paticular configuration.

Unfortunately X Windows has had this cronic problem were it can't realy interact with Linux systems developed to make desktop life easier.. Instead it's always had to depend on it's own drivers and configurations to deal with configurations that has been always independant from the rest of the OS. Hopefully with X.org being modular now modernizing all this will be much easier for devs to fix.

Eventually it'll get to the point were when you setup X you'll have the configuration program look for devices thru the 'HAL' to configure in this manner. It'll ask "What driver do you want to use for "Logitec Optical USB mouse"?" rather then you having to figure all this out and tell it what devices you want and how configure it.

For harddrive and file system devices they have this 'EVMS' stuff that is being worked on that I don't know much about because Debian doesn't use it by default (although you can migrate your systems to it after install time)


My point was that this new 'LABEL" stuff was a step in the right way to try to fix this and although it's disconcerting at first N0c should learn to love, rather then hate. 🙂

 

[Nothinman]

Basicly the problem is is that device names are determined by first come first serve. It depends on the order that the devices are detected. If you change something in the kernel or change how the hardware is arranged then probably you change the order that they are detected and thusly change the /dev name.

I know, but it's not something easily fixed. There's no easy, programatic way to name those devices.

Driver "mouse"
Option "device" "/dev/input/mouse0"

I can go:

Driver "evdev"
Option "name" "Logitech Optical USB Mouse"

Maybe. But then people will be complaining that when they plug in a new USB mouse at work it doesn't automatically works but if you use /dev/input/mice, it would have. And you lose the "treat everything as a file" philosophy that so many unix users like.

Otherwise /sysfs and udev (and hal I suppose) are the 'real' solution to this problem that Linux/Freedesktop.org people have devised. It's now nearly possible to use udev to set /dev/ names that remain consistant irregardless of this or that paticular configuration.

It's been possible for quite some time. When Gregkh first released udev he included a perl script that would query cddb and create a symlink in /dev with the name of the audio CD inserted.

For harddrive and file system devices they have this 'EVMS' stuff that is being worked on that I don't know much about because Debian doesn't use it by default (although you can migrate your systems to it after install time)

AFAIK EVMS is just a naming layer on top of the current device mapper and LVM stuff in the kernel, the core EVMS stuff was dropped because it was a huge duplication of effort.

 

[drag]

Originally posted by: Nothinman

Basicly the problem is is that device names are determined by first come first serve. It depends on the order that the devices are detected. If you change something in the kernel or change how the hardware is arranged then probably you change the order that they are detected and thusly change the /dev name.

I know, but it's not something easily fixed. There's no easy, programatic way to name those devices.

Driver "mouse"
Option "device" "/dev/input/mouse0"

I can go:

Driver "evdev"
Option "name" "Logitech Optical USB Mouse"

Maybe. But then people will be complaining that when they plug in a new USB mouse at work it doesn't automatically works but if you use /dev/input/mice, it would have. And you lose the "treat everything as a file" philosophy that so many unix users like.

Well I believe it still goes thru /dev/input/ stuff for the actual program.. it's just abstracted some.

And /dev/input/mice only works for certain things.

Like if I try to use a tablet with the wacom drivers I can't use mice with my mouse. I have to use the event# device for my mouse because it takes input from all 'mouse' devices so when I use the table I will get X using BOTH the /dev/input/event# for my tablet drivers with the extensions and the /dev/input/mice file with the generic mouse driver.. which doesn't work out that well. So basicly if I want to use Gimp with pressure sensitivity and whatnot then /dev/input/mice is strictly off limits.

Also the same thing would happen if your using the synaptic driver for your mouse and it was incompatable with a paticular USB mouse you'd like to use. You'd have to not use the /dev/input/mice file if you want it to work and get all the features.

As it is now If I want to utilize all the features of my USB input devices... joystick, wacom tablet, mouse, trackball; I have to manually reconfigure X, log out, restart X and log back in whenever I plug them in in order to use them.

For harddrive and file system devices they have this 'EVMS' stuff that is being worked on that I don't know much about because Debian doesn't use it by default (although you can migrate your systems to it after install time)

AFAIK EVMS is just a naming layer on top of the current device mapper and LVM stuff in the kernel, the core EVMS stuff was dropped because it was a huge duplication of effort.


[/quote]

Ya I remember that now. The choice for 2.6 kernels was either lvm2 or Evms stuff and they choose lvm2.. so evms is/has working/has worked to port their stuff to use that instead.

I kinda like the /dev/mapper stuff with lvm2 actually. That way I can configure the device files to suite my personal preference.

 

[n0cmonkey]

Originally posted by: drag
I don't know...

I know that device naming and numbering is something that is fundamentally broken on Linux machines.

It's based on a first come first serve setup. It's a huge problem with USB devices.. for instance If I plug a mouse in first then my tablet then my configurations have to go:
/dev/input/event1 == mouse
/dev/input/event2 == tablet.

When I plug my tablet in first It goes:
/dev/input/event1 == tablet
Then if I want to play a game with my joystick then that makes the mouse:
/dev/input/event4 == mouse

And then don't even ask what goes on when I unplug my keryboard or try to use my trackball.

So thats screwed.

Now tell me what happens now in my server when I have the onboard IDE and 2 identical PCI SATA cards? What happens if I need to rearrange the cards to plug in a new device? What happens when I add a 3rd PCI card and a couple more drives?
I have:
/dev/hda = onboard IDE
/dev/hda1 = 'software raid'
/dev/hdb = DVD burner
/dev/sda = PCI slot 2, Sata drive 1
/dev/sda1 = 'software raid'
/dev/sda2 = /boot
/dev/sdb = PCI slot 2, Sata drive 2
/dev/sdb1 = 'software raid'
/dev/sdb2 = swap
/dev/sdc = PCI slot 4, Sata drive 1
/dev/sdc1 = 'software raid'
/dev/sdc2 = reserved
/dev/md0 = MD 'software raid 5'
/dev/mapper/picardVolumeGroup-<hostname><mountpointname>
(repeat 10 times)

It's a Xen system and I have 5 hosts configured to run on it.

Now tell me what happens If I plug a second drive into the second Sata to PCI adapter AND I add two more drives to a new PCI adapter on slot 3. Should I move the PCI adapters around to try to preserve the /dev/ names? Would that even work? What If I want to migrate the drives to a different machine?

The traditional numbering method works when you have a static machine, with local storage, and so on and so forth. Now you have machines were the storage is relative to how they are configured on the network with GFS and such.

Now that label stuff is news to me, and it's not going to solve my problems, but it seems like a step in the right direction. If you were aware of Redhat using fs labels to designate file systems, rather then specifying what paticular hardware device these file systems reside on, then it would of made more sense.

Get a second server, it's better for you in the long run. And drop the SATA stuff, go scsi.

Seriously though, you put the stuff in, boot into single user mode, and modify as needed. Not hard, I've done it plenty of times. Heck, if you put things into the right PCI slots, you shouldn't have to do as much work.

 

[n0cmonkey]

Originally posted by: drag

Originally posted by: Nothinman

I know that device naming and numbering is something that is fundamentally broken on Linux machines.

Then how should it be done?

Pointing out something that you think is a problem is one thing, but finding a solution that actually works well is another.

well.. DUH. 🙂

I know something is broken, but I don't know how to fix it. It's a fairly common occurance in my life, although it's less common for software then it used to be.

Basicly the problem is is that device names are determined by first come first serve. It depends on the order that the devices are detected. If you change something in the kernel or change how the hardware is arranged then probably you change the order that they are detected and thusly change the /dev name.

And if you have all your configuration based on /dev name then your screwed and things break.

For the device naming for USB devices you can now name them in your X.org config by part of of their USB identity strings that they send to the computer.

Instead of going:

Driver "mouse"
Option "device" "/dev/input/mouse0"

I can go:

Driver "evdev"
Option "name" "Logitech Optical USB Mouse"

Also you can now refer to devices by their USB number and various other identifaction strings. You can find the names and such for devices by looking at /proc/bus/input/devices

Otherwise /sysfs and udev (and hal I suppose) are the 'real' solution to this problem that Linux/Freedesktop.org people have devised. It's now nearly possible to use udev to set /dev/ names that remain consistant irregardless of this or that paticular configuration.

Unfortunately X Windows has had this cronic problem were it can't realy interact with Linux systems developed to make desktop life easier.. Instead it's always had to depend on it's own drivers and configurations to deal with configurations that has been always independant from the rest of the OS. Hopefully with X.org being modular now modernizing all this will be much easier for devs to fix.

Eventually it'll get to the point were when you setup X you'll have the configuration program look for devices thru the 'HAL' to configure in this manner. It'll ask "What driver do you want to use for "Logitec Optical USB mouse"?" rather then you having to figure all this out and tell it what devices you want and how configure it.

For harddrive and file system devices they have this 'EVMS' stuff that is being worked on that I don't know much about because Debian doesn't use it by default (although you can migrate your systems to it after install time)


My point was that this new 'LABEL" stuff was a step in the right way to try to fix this and although it's disconcerting at first N0c should learn to love, rather then hate. 🙂

Nothing was broken, no fix was necessary. It makes more sense for USB, hell even OpenBSD has a hotplugd for removable parts. But it makes no sense for large RAID arrays.

 

[Nothinman]

Get a second server, it's better for you in the long run. And drop the SATA stuff, go scsi.

For most people SCSI is too expensive, especially if you want anywhere near the same amount of disk space. And SCSI is moving to serial attachment as well, there are already several SAS drivers in the kernel and from what I read on lkml SAS controllers will be able to handle SATA drives, not sure if the opposite will be true though.

 

[n0cmonkey]

Originally posted by: Nothinman

Get a second server, it's better for you in the long run. And drop the SATA stuff, go scsi.

For most people SCSI is too expensive, especially if you want anywhere near the same amount of disk space. And SCSI is moving to serial attachment as well, there are already several SAS drivers in the kernel and from what I read on lkml SAS controllers will be able to handle SATA drives, not sure if the opposite will be true though.

But we aren't talking about most people, we're talking about big ass servers. Most people don't have big ass servers. 😉

 

[Nothinman]

But we aren't talking about most people, we're talking about big ass servers. Most people don't have big ass servers.

Agreed. But I assumed what drag was describing was a home server, having a half dozen drives and a few Xen instances at home doesn't seem too far fetched for me. But if it was a made up scenario, then yes they should have spent their made up money on appropriate hardware =)

 

[n0cmonkey]

Originally posted by: Nothinman

But we aren't talking about most people, we're talking about big ass servers. Most people don't have big ass servers.

Agreed. But I assumed what drag was describing was a home server, having a half dozen drives and a few Xen instances at home doesn't seem too far fetched for me. But if it was a made up scenario, then yes they should have spent their made up money on appropriate hardware =)

And this stuff makes a lot more sense at home, to me, than it does on an enterprise server.