[Novalug] Device naming.

[Bryan J. Smith]

I do have to say, you're entertaining ...

To go block by block ...

1) Yes, LVM is just a Disk Label, like the Extended Disk Label.
It just offers far more powerful management features.  But in the end,
beyond the journaling, beyond the snapshot and other options, it
is -- at its most basic form -- a way to set sector ranges for the kernel's
Device Mapper facility (the same facilities for "raw" disk slices as well)
-- with _0_ impact to the kernel block operations.  That's no different
than more simplified "raw" disk slice that the firmware (like the PC BIOS)
expects, that the kernel has to read and store for block operations.

2) LVM, you don't have to pick a size.  You can expand
your disk slices at will.  You can even move them between disks ...
while the system is up and using the filesystem!  I just had a long-time
LVM user not know this the other day, and wouldn't you know, it was
much faster than rsync (let alone faster than 2 rsyncs, which is what
pvmove does -- full verification before and after the move)

How?  LVM is just a more intelligent and automatically managed way
to tell the kernel (via DeviceMapper) where the slices sectors start
and end, possibly striped, cat'd or other, complex organization as
well.  LVM can also define read-head on a slice-by-slice basis, and
countless other features.  And all changes are logged.

There are so many features to LVM.  Snapshots is probably a major
favorite of many -- especially read/write snapshots.  One base system
install that is running under multiple VM guets (e.g., multiple web server
instances), each with their own snapshot of changes, drastically
reducing disk utilization on a physical system.

3) Third ... well, this is what we get.  We all know that us "dumb ****s"
can't seem to provide you "non dumb ****s" with the advanced, "just
what I expect to read and understand" documentation.  And we know
you don't like to read other things and experiment with what we provide.

4)  LVM removes the reliance on having to know anything about
the device naming, enumeration, etc...  LVM "behind the scenes" uses
UUIDs _ensure_ the devices are what they are, and labels to present
them in a useful form.  E.g., my server has ...

  /dev/vg_d5raid1/root
  /dev/vg_d5raid1/swap
  /dev/vg_d5raid1/tmp
  /dev/vg_d5raid1/var
  /dev/vg_d5raid5/usr
  /dev/vg_d5raid5/srv
  /dev/vg_d5raid5/e_home
  /dev/vg_d5raid5/e_static

Now not knowing a thing about my home server, can you figure out
where they are mounted (especially after I tell you "e" stands for
/export)?  Can you do the same with Windows?  DOS?  Or does one
have to make assumptions?

I can take my drives out, put them in another system and guess what?
They will come up as the exact same!  In fact, I've done this over the
years for my "dilbert" home server (the "d5" indicates dilbert5 --
server incarnation #5).

Getting more advanced, I don't have to deal with people using an incorrectly
assigned and presented SAN storage.  If things show up, then it's wrong.
If things don't, then it's wrong.  LVM _forces_ UUID assignments, but makes
them very, very transparent.

5)  Drive letters are magically auto-assigned in Windows as well, let alone
when you _move_ them between systems, have conflicts, etc...  Whether it
is Disk Manager in Windows, or udev rules in Linux (and yes, they have GUI
tools to write them), you have to "tie them down."  In Windows, it's limited to
a simple drive letter.  In Linux, _you_ can label it whatever you want.
Heck, Linux even interprets FAT and NTFS serial numbers like UUIDs too.

Case-in-point:  

100%, absolutely 100% of your arguments are based on 100% assumptions
that you make "how a system should work" and that is 100% pidgeon-holed
on a platform that used drive letters because it didn't even have the concept
of a directory tree when it was created!  Even worse, it had to "borrow" from
UNIX to get directories, redirection, etc...

6)  Just what distro/version are you running?  We have "Gentoo" to work
with.  That could mean anything.  You mentioned 2004 or something.  Well,
some 6+ years ago, I guess that's what Gentoo did, and new facilities haven't
been built to add the good stuff (?).

7)  See #3.  No one seems to provide anything you won't reject.  Honestly.
I'd love to sit down at a meeting and teach you.  I would quickly recognize
whether or not it is as difficult to 

8)  Many of us have studied Tannebaum, Knuth, et al., both informally and
as part of a formal education.  Minix has been cited.  Tannebaum said many
things to Linus early on about Linux.  My personal favorite is the MMU comment.
There is a major difference between simple concepts of academia and
real-world implementation.

E.g., In the '90s, CS majors designed IA-64 thinking they could optimize at
the instruction set, and Digital Semiconductor engineers (who were the most
knowledgeable on the subject) said pure EPIC and Predication would cause
Itanium to fail (and not because of limited x86 compatiblity) and they were
right (and IA-64 has merged in Alpha technologies ever since).  We can play
this "academics" and "this is how this should be built" simplification all-day,
but that doesn't remove the reality of what systems really are ... complex in
the real world.

9)  See #8.  In fact, if you designed a new operating system, you'd either go
the route of Tannebaum, or Linus -- one controls it, one doesn't and accepts
the changes people make.  That's Minix v. Linux right there.  ;)

10) Remove any references to your optical drive in /etc/fstab.  Everything
will work (assuming your system wasn't built some 6+ years ago).

11)  Physical Volumes (PV), Volume Groups (VG) and Logical Volumes (LV)
are the three (3) elements in LVM.  The Linux terminology and approach is
heavily modeled after HP/UX with other considerations.

12)  See #2.  You don't have to pick a partition size with LVM.  That's one
advantage you can have off-the-bat with LVM.

13)  If a drive comes with a filesystem, it will available as:  
  /media/(DOS/Windows label) or possibly just /media/disk[#]
Automagically by udev-HAL-DBUS-gvfs.

If you want to re-slice it, umount, use cfdisk to slice as you want (possibly
make it type 8Eh for LVM), run "partprobe" to update the physical disk label
and slices in the kernel and create filesystems (or LVM volume groups and
logical volumes -- possibly adding to an existing volume group) with labels
as you see fit.

You can then either use UUIDs or labels to add them to /etc/fstab, or if you do
not, the slices will now, automatically under /media/(newlabel) for each new
slice you created, or /media/disk[#] for those that you did not.

14)  See #3 and #7.

15)  The code is there.  It's just more complex than academia-level
implementation today.  Re-read #8 and #9.  ;)

16)  See the "case-in-point" in #5, then #3 and #7 again.

17)  Your "best guess" is based on the same "case-in-point" in #5.
It is directly related to #3 and #7 yet again.  None of us "dumb ****s" are
capable of giving you any answers that don't cause you to throw fits,
reject them or otherwise explain to you how it's better than DOS, Minix,
academia or a simple C program.



----- Original Message ----
From: Alan Grimes <agrimes at speakeasy.net>

1)  Okay, it seems you simply mean extended partitions, OK... =P

2)  You know what? I've not had to give partitions any thought in many a
long year. I'm happy with that...
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.

3)  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.

4)  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. =|

5) 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...
The way I see it, I have to do more work on linux to manage physical
volumes than I do on DOS.

6)  That's a crock of bull, see below.

7)  SHOW ME THE DOCS.
SHOW ME THE DOCS.
SHOW ME THE DOCS.

8)  I have half a dozen nice thick textbooks on the theoretical
underpinnings of operating system design. =|

9)  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.

10) 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. =(

11)  I've never heard of either of those tools.

12)  Again,
-- Because I don't need any of those features.
-- 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. =|

13) What about the new drive? How will it be mounted (the mount point would
be provided in the though experiment).

14) 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.

15)  If I don't know enough to open a C compiler and rewrite it, I'll never
trust it. =|

16)  I'm sick to death of being sent back to square 1 with linux. =|
If you understood how I really felt, you would marvel at my self restraint.

17)  Because I have no documentation, I don't know where these changes
started from so I made my best guess.