adding second SCSI drive
scooter6
OpenServer 5.0.4 and has filePro on it as well (I know several posters
here also use filepro)
I realize the 'correct' thing to do is upgrade the entire system, but
I have some time restraints currently, so I'm looking somewhat for a
quick fix.
This system has an Adaptec (alad) SCSI adapter with only 1 2GB SCSI
hard drive
that is very full.
I want to add a second (and much larger) SCSI hard drive and move the
filePro data to this drive. Currently, the filepro data sits in a
directory called
/u/appl
Am I correct in thinking I can add the new SCSI hard drive, run mkdev
hd (twice)
using the entire drive for UNIX, then running mkdev fs and creating a
filesystem (/u) ..... then I get a little fuzzy here....it's been way
to long since I've done any of this........keeping in mind that all
the filepro menus,
processes, etc point to things like /u/appl/fp/rreport so, I don't
want to have to go in and change all of those to a different path, etc
Can someone simply quick list the steps to accomplish this (they run
full backups every night as well)
Thanks for any input........
Scott Ullmann
Stephen M. Dunn
$Am I correct in thinking I can add the new SCSI hard drive, run mkdev
$hd (twice)
$using the entire drive for UNIX, then running mkdev fs and creating a
$filesystem (/u) ..... then I get a little fuzzy here....it's been way
$to long since I've done any of this........keeping in mind that all
$the filepro menus,
$processes, etc point to things like /u/appl/fp/rreport so, I don't
$want to have to go in and change all of those to a different path, etc
You've already got several of the steps. Oh, and don't forget
the first few steps - make a complete backup; verify it; make sure
your emergency boot diskettes work. You'll never feel like an
idiot for spending time on this and not needing it because the
upgrade worked smoothly, but you _will_ feel awfully stupid if
you skipped this part and then ran into a problem.
Once you've created the new filesystem, go into single user mode
(so that you know you don't have any processes trying to access the
data while you're trying to copy it), mount the new filesystem somewhere
_other_ than /u (I use /mnt for this), and copy the data across. Two
possible commands for this copy:
copy -lmorv /u /mnt
or
cd /u;find . -print|cpio -padlmv /mnt
(I know the second one works - I've been using it for years - but I
think the first one should do it, too, and it's less typing.)
This will take all of the files in /u and move them to the new
filesystem, with the same directory structure.
Now that the data is copied over, unmount the new filesystem
and make sure the system will mount it on /u when you go
multi-user. Depending on how you interacted with mkdev fs, it
may already be configured this way; look at /etc/default/filesys
and see if you see something like:
bdev=/dev/u cdev=/dev/ru \
mountdir=/u mount=yes fstyp=HTFS \
fsck=dirty fsckflags= rcmount=yes \
rcfsck=dirty mountflags=
The important parts are bdev, cdev, mountdir, and rcmount; with
just those four entries present and correct, it will automatically
mount the filesystem in the right spot each time you go multi-user.
Bring the system up, make sure the filesystem mounted properly
(use mount to check), make sure the app works. Reboot into
single-user mode and toast the contents of /u to free up space on
your first hard drive; leave the /u directory itself in place,
because you need it there in order to mount your new filesystem.
Kick back and have a beer.
--
Stephen M. Dunn <ste...@stevedunn.ca>
>>>----------------> http://www.stevedunn.ca/ <----------------<<<
------------------------------------------------------------------
Say hi to my cat -- http://www.stevedunn.ca/photos/toby/
Bela Lubkin
[a new hard drive has been added, defined as /u, and old /u data copied
over to it -- old /u being a directory of the very full root filesystem]
> Bring the system up, make sure the filesystem mounted properly
> (use mount to check), make sure the app works. Reboot into
> single-user mode and toast the contents of /u to free up space on
> your first hard drive; leave the /u directory itself in place,
> because you need it there in order to mount your new filesystem.
At that "toast the contents of /u" step... be careful!
Stephen says "Reboot into single-user mode". In part, he means "make
sure your shiny new /u is not mounted". Rebooting will generally ensure
that, but there are ways you could prevent it. Also, some readers may
have a mental shorthand for "reboot into single-user mode", where they
instead run `init 1` or `init S`. Those commands take you into
single-user mode with non-root filesystems still mounted.
If the new /u was still mounted, "toast the contents of /u" would blow
away the new copy. That alone wouldn't be catastrophic, since the
underlying /u directory (on the root filesystem) would still be there,
as would the good verified backup you made. But -- in the ensuing
confusion, the root copy might get damaged; and 10% of the readers will
do this without making a good backup, no matter how hard you urge...
So, the idea is:
make good verified backups
tell the kernel about the new drive
mount it somewhere (not /u)
copy the contents of /u onto it
unmount it (whether by rebooting or whatever)
double-check that /u is now just a directory on the root filesystem
[you can run `df -v / /u`; the "Filesystem" column in the output
shows the device names corresponding to each directory; for
instance:
$ df -v / /etc
Mount Dir Filesystem blocks used free %used
/ /dev/root 13880000 6445536 7434464 47%
/etc /dev/root 13880000 6445536 7434464 47%
$ df -v / /u
Mount Dir Filesystem blocks used free %used
/ /dev/root 13880000 6445536 7434464 47%
/u /dev/u 71649900 44609306 27040594 63%
Notice that / and /etc have the same device node and stats --
they're on the same filesystem. / and /u are on different
filesystems.]
delete the contents of /u
make sure a /u directory exists in the root filesystem, is empty, and
has permissions 755
mount the new drive onto /u
>Bela<
Tony Lawrence
> I have to add a new SCSI drive to an existing system that runs SCO
> OpenServer 5.0.4 and has filePro on it as well (I know several
> posters here also use filepro)
>
> I realize the 'correct' thing to do is upgrade the entire system, but
> I have some time restraints currently, so I'm looking somewhat for a
> quick fix.
>
> This system has an Adaptec (alad) SCSI adapter with only 1 2GB SCSI
> hard drive that is very full.
>
> I want to add a second (and much larger) SCSI hard drive and move the
> filePro data to this drive. Currently, the filepro data sits in a
> directory called /u/appl
See these articles:
http://aplawrence.com/Unixart/moredisk.html (covers adding a drive and
moving existing data)
http://aplawrence.com/Unixart/newdisk.html (more detail on the adding part)
--
Please note new phone number: (781) 784-7547
Tony Lawrence
Unix/Linux Support Tips, How-To's, Tests and more: http://aplawrence.com
Free Unix/Linux Consultants list: http://aplawrence.com/consultants.html
Tom Parsons
I'll take a contrarian approach from everyone else (who gave given the
advice you asked about).
A 2 gig drive is old, slow and you would be hard pressed to find a replacement
drive smaller than 18 gig. And, if you should, the price differential
is tiny.
I'd replace the 2 gig drive with an 18 gig. The 18 gig will be considerably
faster, if for no other reason than its size.
--
==========================================================================
Tom Parsons t...@tegan.com
==========================================================================
corrlens
> possible commands for this copy:
>
> copy -lmorv /u /mnt
> or
[ snip ]
I played (just for fun in the same harddrive) with the copy command you
mentioned (copy -lmorv /usr2 /usr3) and it seems it just creates links
because it was so fast and after running "df -v" I have the same hard drive
usage.
Is that what it normally does if using the same drive ?
ms71270
> I'd replace the 2 gig drive with an 18 gig. The 18 gig will be
considerably
> faster, if for no other reason than its size.
>
> --
> ==========================================================================
> Tom Parsons t...@tegan.com
> ==========================================================================
I don't think the assumption that bigger drives are considerably faster then
smaller drives always holds true. An 18 gig drive should be based on newer
technology thus being faster then the 2 gig, but not just because it is
bigger. My 18 gig 15K drive is faster, and smaller then my 36 gig 10K
drive.
Tom Parsons
|
| > I'd replace the 2 gig drive with an 18 gig. The 18 gig will be
| considerably
| > faster, if for no other reason than its size.
|
| smaller drives always holds true. An 18 gig drive should be based on newer
| technology thus being faster then the 2 gig, but not just because it is
| bigger. My 18 gig 15K drive is faster, and smaller then my 36 gig 10K
| drive.
A 18 gig drive with the same characteristics (rpm, seek times, etc) as
a 2 gig drive will always be faster than the 2 gig provided the information
is loaded at the beginning of the drive, which would be the instance here.
Data transfer speed decreases from as the platters are filled from the
outside in.
Now if his 2 gig drive has 15 physical heads and 8 physical platters, I might
agree but I have serious doubts he has such a beast.
Stephen M. Dunn
in this thread. It will NOT create an exact copy of your data in
one very common situation. The cpio command which I provided should
be used instead. Here's why.
In article <GLtD9.2693$Cg2.18...@newssvr21.news.prodigy.com> "corrlens" <a...@sbcglobal.net> writes:
$> copy -lmorv /u /mnt
$I played (just for fun in the same harddrive) with the copy command you
$mentioned (copy -lmorv /usr2 /usr3) and it seems it just creates links
$because it was so fast and after running "df -v" I have the same hard drive
$usage.
$
$Is that what it normally does if using the same drive ?
Yes - as will the cpio command I also provided. In both cases,
I used the options which create hard links if possible - more out of
habit than anything for cpio, and I did the same with copy in an
effort to make the commands have as similar an effect as possible
(oops).
If you do this from one filesystem to another, hard links are not
possible, so it will copy the data. If you leave the -l out of the
cpio command, nothing bad happens; files which are links on the
source filesystem become links on the destination filesystem, as you
would normally want. This is the situation in which the copy command
does NOT do what I wanted it to do - more info below.
If you do this from one spot on a given filesystem to another,
hard links _are_ possible, so both cpio and copy use them to preserve
disk space if you give the -l option.
Why the copy command should NOT be used for migrating a directory tree
----------------------------------------------------------------------
Even with the -l option, it does not preserve links (at
least, not on this box - OSR5.0.5 with rs505a and pretty much every
other patch) when copying to a new filesystem.
Example (assuming /u and /tmp are two separate filesystems to
which you have write access):
--------------------8<--------(cut here)--------->8-------------------
#!/bin/sh
#
# Create source directory. Source contains:
# file1 - a file with no links
# file2 and link2 - two links
#
cd /tmp
mkdir source
cd source
date > file1
date > file2
ln file2 link2
#
# Create target directory and copy data
#
mkdir /u/dest
copy -lmorv . /u/dest
#
# Demonstrate that the source and target are different
#
echo Source directory
ls -li
echo Target directory
cd /u/dest
ls -li
--------------------8<--------(cut here)--------->8-------------------
The listing of the source directory shows that link2 and file2
are links to the same inode; the listing of the target directory
shows that they are completely separate files.
Replace the copy line with:
find . -print|cpio -padmv /u/dest
and you'll find it works properly.
If your source directory tree has no hard linked files in it,
then the copy command can safely be used. You can check this
with
find source-directory-name -links +1 -type f -print
which will print out a listing of all files with more than 1 link,
but there's less typing if you just use the cpio command :-)