Making big ones out of little ones [was: tlug: Debian install...]

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "Ulrike" == Ulrike Schmidt <ulrike@example.com> writes:

    Ulrike> I have Windose completely erased

Aha, a convert!

    Ulrike> ... booted with a system-disc but it does not recognise
    Ulrike> any drives besides a: and b:, guess this does not count as
    Ulrike> a test

No, those drivers will normally live in C:\WINDOWS somewhere.

    Ulrike> ... I am completely ignorant when it comes to hardware and
    Ulrike> so I won't touch the box today, but just a minute ago
    Ulrike> someone came in, told me that there is a spare scsi-board
    Ulrike> somewhere and probably also a spare cdrom and that I
    Ulrike> should ask my sensei about those when he is back, so I
    Ulrike> have to postpone this probably until Thursday.

    Ulrike> What a pity, they were having doubts about Linux and
    Ulrike> hardware and I said "no problem!" ... :-(

You need to borrow Austin or Jim for a couple hours ;-)

    Ulrike> Now this sounds interesting ... I was wondering how I
    Ulrike> could treat some of my hardiscs as a single one,

MD (RAID) is probably not the way.  There are applications with very
large (I'm talking order of terabytes) single files, and other
applications where doubling (or x8) the speed of burst disk I/O is
important.  In those cases larger than individual disk-sized files can
be achieved by using linear appends of more disks to a single
partition, or partitions can be "striped" so that all bit0 for each
byte comes from disk0, bit1 from disk1, etc, which (with appropriate
OS software, firmware in the disk controller, and a fast CPU) allows
you to read 8x as fast.  Or for high reliability, you can arrange that
disk0 and disk1 always do exactly the same writes off the controller,
so that they are always exact mirrors of each other.

But that's not really sensible for most setups: few people need 1GB
files, let alone 1TB files, long bursts of disk I/O at 8x normal
rates, or submicrosecond backups.  Eg, I'm looking at a 1GB partition
mounted on /usr, and that's just not going to cut it if Debian keeps
adding packages at the current rate.  So I can add 33% free space to
that partition by creating a 500MB partition somewhere (say
/dev/sdb1), formatting it, mounting it to /tmp/share, copying
/usr/share recursively to /tmp/share, then adding

/dev/sdb1 /usr/share ext2 defaults 0 2

to /etc/fstab, and doing `diff -rq /usr/share /tmp/share >
/tmp/just-for-grins' to make sure everything's OK before doing rm -rf
/usr/share; mkdir /usr/share; umount /tmp/share; mount /usr/share.

    Ulrike> just took the mountpoints for each drive as suggested by
    Ulrike> the installation disks, but I guess I have a weird
    Ulrike> partition setup now ... The suggestions for partition
    Ulrike> sizes in the handbook that came with the Debian CDs gave
    Ulrike> some examples but said these setups were not optimal, why
    Ulrike> didn't they give a better example then? Maybe "as many
    Ulrike> suggestions as sysadmins" or something along these lines

Partly that, but partly it depends on your usage.  I, for example,
have 350MB in ~/Projects/XEmacs alone, and if I'm not careful about
doing make cleans that can easily balloon to 500MB.  ;-)  But most
people can get along with 500MB for all of /home on a multiuser
system.  The Coda network file system is most efficient with 3
partitions of its own for the server (one of which only needs to be
50MB or so but should be on a separate disk!), and at least one extra
partition for the client.  Surely you don't expect the Debian guys to
handle such oddball situations in the initial install!!  But the thing
is, just about everybody has some idiosyncracy that demands special
treatment.

    Ulrike> ... I will check the tlug archives, I remember partition
    Ulrike> sizes have been discussed here before. But how do I make
    Ulrike> one out of two?

Don't, just pick an appropriate subtree and move it to an empty
partition.


-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."
--------------------------------------------------------------------
Next Nomikai Meeting: April 20 (Thu) Linux Conference 2000 Spring Ed.
Next Technical Meeting: May 13 (Sat) 13:30 Temple University Japan
* Topic: TBD
--------------------------------------------------------------------
more info: http://www.tlug.gr.jp        Sponsor: Global Online Japan