[Novalug] Device naming.

[Peter Larsen]

On Mon, 2010-03-15 at 18:09 -0400, Alan Grimes wrote:
> Peter Larsen wrote:
> > On Mon, 2010-03-15 at 11:04 -0400, Alan Grimes wrote:
> 
> > Yes - use LVM and not partitions.
> 
> Okay, it seems you simply mean extended partitions, OK... =P

Not at all. With LVM I don't even create a partition table. Well, for my
boot-drive I have to due to BIOS limitations, but hopefully that won't
be long. I usually "quipe" when people want to compare a logical volume
to a partition - but if it helps you understand the concept, you create
logical partitions with LVM. Logically from an admin perspective it's an
indefinite number of partitions (volumes). Even better, you're not bound
to a disk. You bundle your disk together into groups - and LVs can spand
several disks in the same group. So when you need more room on your old
200G drive, you can use LVM by simply adding a new disk, extend your
volume group and enlarge the volumes that you need more space in. Or
simply migrate your LVs from your old slow disk to the new one, while
the system is running, and quite efficiently. When you boot, no need to
configure /etc/fstab or anything. 

> > Another good reason then. You've already identified many of the pitfalls
> > of partitions. Why not break that barrier and make life easier?
> 
> You know what? I've not had to give partitions any thought in many a
> long year. I'm happy with that...

And there lies the problem. Partitions have always been a problem. For
migration, backup and flexibility reasons. In particular the
incompatibility between bios and the DOS MBR. Remember when the boot
partition had to be allocated below cylinder 1024? It's so inflexible
that nobody really likes it. We've lived with it because it was what
everyone supported; but now we've finally found a way out of the
darkness of a PC/DOS partition table.

> Going forward, I'm going to have to pick a size for the partitions on my
> new machine, that's giving me a minor headache, but I'm not up in arms
> about it.

Here's a standard layout for an Ubuntu or Fedora today:

/dev/sda1 - Utility partition (vendor specific)
/dev/sda2 - 150M /boot
/dev/sda3 - "windows" NTFS if you dual boot
/dev/sda5 - PV (LVM physical volume)

You'll create a single volume group, named for instance vgsys (you can
choose any name). And then at least 2 volumes: lvswap and lvroot. I
would recommend adding one for home too. 

Now when activated, you'll find your "partitions" in /dev/vgsys/lvroot
and as /dev/vgsys/lvhome. Your swap is /dev/vgsys/lvswap. Much more
telling than /dev/sda, /dev/sdb etc.

> >> /me recites his mantra
> 
> >> SHOW ME THE DOCS!!!
> >> GIVE ME LINKS!!!!
> >> GIVE ME GOOGLE SEARCH TERMS THAT WILL FIND THE DOCS IN THE FIRST TEN
> >> RESULTS!!!
> 
> > Who cares? It doesn't matter if you get the docs or not. You've already
> > made up your mind, and you've clearly stated you refuse to read or learn
> > about anything that your preconceived mind has already decided it's
> > opinion about. And the documentation and references you've been given
> > you've ignored.
> 
> I've looked at the docs that people have linked to. They don't cover the
> subjects that I need to understand in order to have any peace of mind.

They've covered every subject we have talked about here. Some of them
even at such a detail that reading them end-to-end would take a very
very long time. I would recommend looking at Redhat's documentation.
They have enterprise guided documentations, both detailed and high
level, for pretty much any area on a standard Linux server.

> > Instead you behave like we owe it to you to solve your problems. And
> > because we don't, you get angry at us and at the world. I think most of
> > us here subscribe to the mantra, that it's better to teach a man to
> > fish, than give him one. In that kind of world, if you don't like how to
> > fish, you'll starve. And from your utterings here, I'm sure you'll
> > starve blaming everyone else in the process. 
> 
> =P
> That's silly...
> Who do you think changed all these things that used to work for me for
> many many years. -- Hint: I didn't do it to myself! =P

Exactly my point ... I'm sure my granddad would still proclaim that the
world was easier and simpler when the "Whites Only" signs were up. That
doesn't mean it was a better world ... I don't think I can illustrate it
any clearer than that. Things change.

> > Ohh like you retreat to throwing out empty postulates and unfounded
> > accusations? 
> 
> It's not like I have any documentation to work from...

The rest of us seems to have no problems finding it? After all, we
learned it somehow. Maybe it would be easier if you pointed specifically
in the links we gave you, what subjects they don't cover that you're
looking for?

> >> Then how does it know what partition has my programs and which has my
> >> anime?
> 
> > You still haven't read any of the pages you've been pointed to? udev
> > rules defines what disk is what - or even better the label/uuid. Kudzu
> > NEVER had anything to do with that anyway.
> 
> That's insane!
> It's a whole other layer of configuration complexity. Here's a bargain:
> You get me a reliable device naming scheme and I'll plug it into my
> directory tree using fstab. If I ever have to change it again before I
> die, I'm going to be out for blood. =|

Again - no, it's not a new layer of complexity. It's letting the
computer do what it's good at, while you can concentrate on what's
really important - getting your work done.

> > You know, I still have an MSDOS 6.22 ISO here that I'll share with you.
> > You could "upgrade" your system and stick with it from now on. I think
> > you would save us all a lot of grief and time if you did. I'm beginning
> > to doubt you even use computers at a regular basis; being linux or
> > windows or anything else. You would know, that one of the biggest
> > complaints from the Windows side is the "c:" limitations.
> 
> I have never uttered such a complaint, nor have I ever heard an argument
> behind such a complaint.

Ehhh - excuse me? Your sea of "DOS did it right" and "It was so much
simpler with DOS"? Do you really want me quote them all here? I think
Bryan's reply enumerating the reasons why you're "off the rocker" when
it comes to drive assignments etc. is a good read for everyone.

> I got me an XP install that decided to install itself on E:. =\

Try to enlarge E: and get back to me when you're done :)

> > While windows has had mount-points for quite a while, it's rarely used or understood
> > by windows admins. But it's there because IT MATTERS and makes life
> > simpler.
> 
> No.
> It's merely different.

That's like saying a bicycle and a car are "just different means of
transportation". 

> > With linux you have one tree. That's it! No worrying about what device
> > your files are on. Programs are simpler; paths are simpler. 
> 
> In a number of cases, I care very much which physical medium my data is
> on. -- especially when planning my allocation of storage, making sure I
> am taking the right data with me if I decide to unplug a drive, etc...

Again, LVM to the rescue :)
But even before that with a single tree, you can still determine what
part of the tree goes to what disk. That's after all what the
mount-points are for.

> The way I see it, I have to do more work on linux to manage physical
> volumes than I do on DOS.

How so? Have you ever tried to move your DOS disks from one machine to
another? Talk about work if even possible.

> > "probably" huh? You'll find that open source are some of the best
> > documented systems out there.
> 
> SHOW ME THE DOCS.
> SHOW ME THE DOCS.
> SHOW ME THE DOCS.

Type in "LVM overview on linux" in google and see what comes up. There's
even a ton of Wikipedia pages out there with nice drawings to explain
it. 

> > At the very least you have access to the
> > source if everything else fails. The kernel most of all. But without
> > understanding the underlying technologies of a kernel, it's not going to
> > be understood by you. No level of explanations or links will fix that.
> 
> I have half a dozen nice thick textbooks on the theoretical
> underpinnings of operating system design. =|

Funny - you don't seem to show much of that knowledge in here. When
Bryan mentioned Tannenbaum I got all nostalgic - I still my got 1986
Tannenbaum book. And it's got a statement highlighted that "soon we'll
see computers with 1 gigabyte of memory" :) hehe - that was biiig back
then.

> I even wanted to develop my own operating system. I even designed it but
> couldn't implement it because I couldn't find documentation on compilers
> and linkers, the shifting sands of PC architecture, and a few other issues.

I see a trend here. There are quite a few O'Riley books out there going
over these subjects too. Maybe you could start here?
http://linuxdevcenter.com/pub/a/linux/2006/04/27/managing-disk-space-with-lvm.html

And yes, I wrote "linux books lvm" in as my search criteria. It's not
that complicated.

> >> I therefore removed and masked HAL from my system, and done everything I
> >> can think of to force xorg to basically behave as TRON did at the IO tower.
> 
> > I'm beginning to think that sending you that DOS 6.22 ISO may actually
> > not work. It's not floppies and I have a feeling you've thrown out CD
> > drives and USB devices taking more than 1.44MB at a time.
> 
> Xine connects to my DVD drive directly and when I need to mount it, I su
> and mount it manually. There doesn't appear to be any other way to use
> linux. =(

Well, don't tell that to mine - it may get ideas and stop working. I
don't think I've manually mounted a CD on my workstation for 2 years
now. On my servers it's done occasionally but it's usually automatic
done in /media for me.

You've stated you've turned off HAL and alot of the tools necessary for
the system to help you. In that case, yeah it won't work. Just like if I
don't pay my electric bill, my lights won't turn on.

> > Find me an IDE (not SATA) disk, and I'll give you a reward. You're
> > killing your own argument though. If the premise is the computer already
> > has a working primary drive, you're assuming it's configured correct
> > already. That means that any additional drive automatically will be
> > assigned to sdb, sdc etc. You can do a lot of assumptions going in. And
> > if you're adding the second drive, you can easily tell your dummy to do
> > an pvcreate /dev/sdb and vgextend. Doing that does ALL the UUID for you.
> > Never have to be concerned or update /etc/fstab or anything. Neat huh?
> 
> I've never heard of either of those tools.

They're LVM tools. 

> Again,
> 
> -- Because I don't need any of those features.

We're trying to teach you, even though your attitude is counter to
trying to do so. Nobody reading this doubts that you don't like changes
in what you have thought was "set in stone" IT theory. We've moved on
and while there's new stuff to learn, the tasks that used to take you
hours or days can be done in minutes now. That's the improvements. 

Your first step may be to "invest" in a modern distribution and see for
yourself how easy things have become since your last install.

> -- Because I have complete understanding of how classical partitions
> work, right down to the binary representation on the drive.
> 
> --->>> I'll continue to use cfdisk. =|

By my guest. But when it comes to hiring the guy who can get the job
done the fastest you may find yourself behind the leading pack.

> >> In the new system you must first *GUESS* (with scant evidence) which of
> >> the sd* devices your new drive is, and then adjust all of your plans
> >> accordingly. If the new drive displaced other drives in the system,
> >> you're SCREWED.... You have to go back and figure out where all of your
> >> drives are again and adjust your fstab accordingly.
> 
> > No fstab change needed - unless you want to introduce new mount points.
> > Again, learn how to use the tools that are there to make things easier
> > for you. 
> 
> What about the new drive? How will it be mounted (the mount point would
> be provided in the though experiment).

Finally a good question. Bryan did answer it, but let me rephrase his
answer. LVM creates device-identifier on the actual disks. This removes
them from sequence of devices in the bios or when you move the disks
from one computer to another. An LVM group always comes up whole
regardless of what sequence you have the disks setup in the bios.

The PV has a UUID. The VG has a UUID. The VG's metadata says what PV
UUIDs are assigned to it. From there it's a simple lookup, and it
doesn't matter if the disk is /dev/sda, /dev/sdd, or /dev/sdz - it just
works.

My example above simply added space to the system. I didn't create new
mount points because I expand the size of the existing ones to cover
both disks. So if my old disk was 200GB and let's say 50G was taken by /
and the 145G was taken by /home and the rest is boot overhead stuff,
after you add the new disk - which we could say was 500G, your / could
be expanded to say 75G and home to 550G. That leaves a little bit of
"unused" space that you can use for backup and snapshot purposes. In the
end you have no new mountpoints but simply more room. 

> >> SHOW ME THE DOCS!!!
> >> I need to know exactly how it works, with no detail omitted.
> 
> > You've been given the links over and over again. You refuse, and have
> > described CLEARLY that you're not interested in learning how things are
> > done now. You want things to work like they did in the 1980s - well,
> > you'll need a time-machine for that, and not even Linux can help you
> > there I'm sorry to say.
> 
> I'm open to change, I merely demand that I
> 
> A: understand the new solution equally as well as I did the previous
> solution.
> B: Find it actually to be preferable. -- Ie genuinely reduces my workload.

I'm not sure I can help you with A. B is pretty easy - LVM, HAL, UDEV
definitely makes your life easier.

> > Redundant. We've even thrown you a few fish but you still don't seem to
> > want to eat because the fish doesn't look exactly like the fish you ate
> > when you were 5 ... or so to speak.
> 
> If I don't know enough to open a C compiler and rewrite it, I'll never
> trust it. =|

I've created compilers in my past academic life. They're NOT that
complicated once you understand the principals of a lexical analyzer and
a state machine. In other words, things can be learned and i've found
Linux to be a great source of knowledge gaining opportunities. 

> > Case in point. You get flamed because you start out flaming, complaining
> > and lecturing when you obviously haven't got a clue. Ask a question, "be
> > nice". A simple: "I used to be able to easily know what my device nodes
> > were named/called to represent my hardware, but I'm unable to do that
> > with XYZ release of Linux - can anyone help me on what to do" would have
> > given you 10x the response you got, and all would have been
> > constructive. Instead you spread your poison and bad vibes by accusing a
> > whole community of "conspiracy" to just get back at you.
> 
> I'm sick to death of being sent back to square 1 with linux. =|

Strangely - from my advantage point that's exactly where you want it?

> If you understood how I really felt, you would marvel at my self restraint.

Ditto.

> > You even sent it to the kernel community as if they were in charge of
> the conspiracy
> > and you single handed had lured them and their dirty tricks. 
> 
> Because I have no documentation, I don't know where these changes
> started from so I made my best guess.

It's there - we've given you links, and the google searches are pretty
easy to learn the basics. And controlling the alias for a new disk
in /dev is "basic" with udev. Creating a basic LVM structure is "basic".
You should pick it up in a matter of hours. There are many advanced
commands that you can postpone till later before you dive into them.

-- 
Best Regards
  Peter Larsen

Wise words of the day:
Avoid the Gates of Hell.  Use Linux
	-- unknown source
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://calypso.tux.org/pipermail/novalug/attachments/20100315/eb1d10fc/attachment.bin