[WYLUG-help] "lost" hdd
Dave Fisher
wylug-help at davefisher.co.uk
Sun Jan 29 18:01:10 GMT 2006
On Sun, Jan 29, 2006 at 04:35:21PM +0000, Mike Goodman wrote:
> Dave, everything you have said is perfectly correct. You may or may not
> believe it, but I had no idea I should have created a new
> directory, /mnt/hda1.
I do believe it. That lack of awareness is entirely consistent with the
readouts you posted.
> The situation has now changed. I tried to install FC4 instead, and found
> I had a duff disc.
That is exactly the kind of urge to action ('something must be done')
that I was encouraging you to avoid.
There are circumstances when giving up and starting again on a different
tack is a cost-effective strategy, but that is rarely the case when you
haven't got a clue about what went wrong in the first place.
For example, if I wanted to install a suite of applications with very
recent version numbers on a standalone machine, it would probably be
quicker to install an alternative distro which was known to have them in
good working order.
On the other hand, when you are talking about basic system configuration
(and especially hardware configuration), it makes little sense to
randomly plump for an alternative distro on the off-chance that it
'might' just work.
If you gave the FC4 installer the same instructions that you gave to the
Debian installer, you would have probably got the same result, i.e.
because you didn't specify a mount point for the other drive during
installation, the installer would not have created a mount point
directory or a mounting 'instruction' in /etc/fstab.
> So reverted to Sarge (using network disc I downloaded
> earlier) - I have got as far as running the installer on hda and the
> installer shows hdb as being the LVM file system so the FC4 installer
> must have gone at least some of its way.
That doesn't sound too good to me.
If you haven't grasped the basics of mounting drives and partitions, I'd
be surprised if you were able to manage an LVM setup sensibly.
One of the many things LVM is useful for, is presenting a simplified
picture of potentially complex hard disk/partition relationships to the
end-user.
On the other hand, it can only do this, if the person who configured it
originally fully understands what they are doing.
> So, I now have hda installed with deb sarge as a web/file/print server
> and hdb doing nothing.
>
> Any takers for how and where I should start on hdb, bearing in mind
> instructions must be idiot proof and simple ? :o)
>
> Should I start by using fdisk to partition hdb? If so, what partion(s)
> should I create?
That's quite a few questions and guesses.
As I've said, several times in this thread, you'll make your task easier
if you deal with one (very small, atomic) issue at a time.
I think it's probably time to go back to the beginning by defining:
1. The primary functions/purposes of the machine
Presumably, to act as a (headless?) web/file/print server?
2. Where your storage media are attached to the motherboard's IDE interfaces
IDE 0,0 hda?
IDE 0,1 hdb?
IDE 1,0 unused?
IDE 1,1 hdd (cdrom)?
3. What partitions/volumes you actually need
One for the root filesystem (definitely!)
One for swapping (almost certainly)
0ne for data (probably)
Having all your data (including things like web sites, databases,
user home directories and logs) all on one branch of the unified
filesystem can make back ups and adding extra storage space a bit
easier, i.e. separating out the bits of the filesystem that can
grow rapidly in size from the basic system.
4. How you map hard disks and hard disk partitions to the unified
filesystem, i.e. which partitions are used to store which
directories under the root irectory (/).
The last of these is the bit which calls for the most experience and
judgement.
I'm sure that WYLUG members will have many different views on this, but
given what we already know of your aims, current knowledge and
experience, I would suggest the following (deliberately simplified)
approach:
a) Stick to using as few _conventional_ partitions as possible,
i.e. I don't think that _you_ (Mike Goodman) should use LVM,
even though I (Dave Fisher) do use LVM for a similar system.
b) Tell the installer to create 4 conventional partitions on your 2 hard drives
/dev/hda1 for the root file system (e.g. 10 GB)
/dev/hda2 for current data (e.g. 39 GB)
/dev/hda3 for swap (e.g. 1 GB)
/dev/hdb1 for extra data storage in future (e.g. all 80 GB)
c) Tell the installer to format /dev/hda1, /dev/hda2 and /dev/hdb1 as ext3
d) Tell the installer to format /dev/hda3 as swap
e) Tell the installer to mount /dev/hda1 as /
f) Tell the installer to mount /dev/hda2 as /home
g) Tell the installer to use /dev/hda3 as swap
h) Do not mount /dev/hdb1 at all until you need the extra storage space
The above should be quite adequate to get the system up and running.
Don't worry about the fact that you'll hardly be using /dev/hda2 and not
using /dev/hdb1 at all.
And don't worry about sub-optimal hard disk performance.
There's no point in doing anything clever to optimise your use of hard
disk space or performance until you actually need to, and until you
really know (from experience) how your needs are changing over time.
Besides, both the space and performance will be more than enough for
your initial requirements.
If/when you do find /dev/hda1 running out of data storage space for
applications like Apache and MySQL/Postgres, you can reconfigure those
applications to store their data and logs in the /home branch of the
filesystem (i.e. on /dev/hda2), e.g.
/home/mysql/data
/home/mysql/logs
/home/www/site1/docs
/home/www/site1/logs
/home/www/site2/docs
/home/www/site2/logs
N.B. To make this work you'll need to:
i) Create those directories using mkdir
ii) Stop the applications concerned
iii) Move the existing data and log files to the correct place under
/home
iv) restart the applications concerned
v) Ensure that the new mount point is listed in /etc/fstab so that it
is used if/when the system is rebooted
If/when /dev/hda2 eventually runs out of space for storing all your data
and log files you can 'repeat' this process with suitable modifications,
utilising the currently unused /dev/hdb1.
For example, if it is your MySQL databases that are growing the most,
you could
i) backup everything under /home/mysql
ii) stop mysql
iii) mount /dev/hdb1 as /home/mysql
iv) restore your databases to /home/mysql which will now be written
on /dev/hdb1 and, therefore, have plenty of space to grow into.
v) restart mysql
vi) Ensure that the new mount point is listed in /etc/fstab so that it
is used if/when the system is rebooted
You'll now see (df -h) 80GB of extra space for your databases under
/home/mysql
N.B. at this stage, your original databases will still exist on
/dev/hda2, but not be visible or usable as part of the unified
filesystem, because they are masked by /dev/hdb1.
Should further data growth mean that you eventually need to
recover/utilise this 'wasted' space on /dev/hda2:
i) Stop mysql
ii) temporally unmount /dev/hdb1
iii) delete all the _contents_ of /home/mysql
iv) remount /dev/hdb1 at /home/mysql
v) restart mysql
df -h will now show a lot more unused space under /home.
Dave
P.S.
Note (for potential contribubtors to the thread)
------------------------------------------------
The above recommendation is not what I would do for my own needs, nor
what I would generically recommend for Linux file/print/web servers.
It is designed specifically to accomodate Mike's limited understanding
of fundamental Unix/Linux concepts and computer hardware, while at the
same time allowing some future flexibility.
It is particularly designed to avoid:
1. Any need to predefine partition sizes and mount point locations
based on guesses about future usage patterns.
2. Any need to understand LVM, volume groups, logical volumes, etc.
3. Any need to carry out configuration tasks before they are strictly
necessary.
Please suggest better ways of acheiving these ends if you can.
More information about the Wylug-help
mailing list