It's not that hard to manage large numbers of devices.

We have Samba servers that are 64 physical volumes.  6 for the system, and two LVM 
volumes of 28 3390-9 disks for a total of 2x204 gb.  We decided on two filesystems 
instead of one big one in case one
gets corrupted.  We can restore the bad one, while the users on the other keep running.

You can script the dasd initialization process and let it run unattended.  It takes 
the better part of a day to format that much dasd, but dasdfmt is the long bit.  
Creating the partitions, running
pvcreate, vgcreate, lvcreate, is quick.  mkfs is a few minutes.

> -----Original Message-----
> From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of
> James Tison
> Sent: Tuesday, January 06, 2004 9:57 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [LINUX-390] New Linux User
>
>
> Hi Mike,
>
> /dev/dasda (major 94: minor 0) is reserved three partitions on it:
> /dev/dasda1 (94:1), /dev/dasda2 (94:2), and /dev/dasda3
> (94:3). Same scheme
> for all the other physical DASD --- the minor value that mod
> 4 returns zero
> on is the unit itself, the other three are its partitions --
> these aren't
> optional. So if you have 91 physical devices, /dev/dasdcm
> looks correct as
> your last device (with its three partitions, /dev/dasdcm1,
> /dev/dasdcm2,
> and /dev/dasdcm3). But I only have 37, so what would I know? :-) Most
> sysadmins have their DASD units emulating 3390-3s, with a capacity of
> approximately 2.3 GB per unit. 91 DASD units makes for a pretty darned
> large system. Basic DASD unit /dev/xxxxx names never have
> numbers in them,
> their partitions always do.
>
> Vic already showed you the mknod command, and Mark (thanks
> again) already
> gave you the major:minor pairs to use for each.
>
> Nobody says you HAVE to partition your DASD (see "man
> fdasd"); but I've
> always put partition tables on mine just in case I want to
> split the disk
> up later. You can also do that with LVM, but let's just stick
> to the basics
> now since you're new. Make one partition (for example,
> /dev/dasda1) on each
> physical DASD. You're going to need to make the system decide
> how to mount
> them onto your filesystem. File /etc/fstab should have a series of
> "mount"-like commands (see "man mount" and "man 5 fstab")
> that force DASD
> partitions to uniquely correspond to points in your filesystem tree at
> which each partition will be mounted.
>
> You can then put a filesystem on each of your partitions as
> you please.
> ext3 is probably the most commonly used, but there are others
> available.
> Have a look at "man mkfs" if you want an idea of what this entails.
>
> 91 units way exceeds what most basic installation programs
> will format,
> partition, and mount up for you unless you spend hours
> entering in device
> labels & mount points during initial installation. Starting off with a
> jumbo system like you have is rarely a good idea if you used
> the standard
> installation program and have never done this before. My
> guess is that you
> could have as little as 1 DASD unit mounted on /, with all
> the other mount
> points on that single DASD unit. Then you'd have 1 unit in use and 90
> sitting there doing nothing. File /etc/fstab will tell you. The "df"
> command will give you a hint what you're using, too. Your first DASD
> unit/partition (/dev/dasda1) should have mount points /etc,
> /bin, /sbin,
> /boot, and /lib on it, at minimum -- your "parmfile" (in /boot/zipl on
> SuSE) should have "root=/dev/dasda1" in it, too ... this is the device
> you'll IPL.
>
> If you didn't understand those last three paragraphs, keep
> reading very
> basic Linux/Unix books until you do. I have no idea _how_ new
> you are to
> all this -- I hope I haven't insulted you. IBM's ITSO website
> has got lots
> of Redbooks you can read about implementing Linux under VM,
> natively, or
> LPARed.
>
> Welcome, by the way.
>
> --Jim--
> James S. Tison
> Senior Software Engineer
> TPF Laboratory / Architecture
> IBM Corporation
> "A bird in hand is safer than one overhead."
>

Reply via email to