[sclug] Debian Squeeze boot up messages: moving on.

Philip Hands phil at hands.com
Fri Feb 22 16:47:53 UTC 2013

Neil Haughton <haughtonomous at googlemail.com> writes:

> 1. I only have PCI slots and IDE sockets (no PCI-E or SATA) on my
> ancient-yet-stalwart motherboard. Reasonably Priced Disks these days tend
> to be SATAII or better, and for a PCI slot it seems I can only get SATA
> adapters, not SATAII.

Sadly cheap SATA cards are often pretty dire.  You might want to
consider replacing the motherboard, or buying something a little more
recent on ebay.

I've had quite good luck with HP Microservers:


I note that Microsoft seems to be getting more and more desperate about
these, trying to tempt the unwary with 500 quid in cashback, but the 100
quid you get back when buying a bare machine seems pretty decent to me
(especially if you're able to reclaim VAT, as that leaves the price at
just 100 pounds for a little server machine, ready to take 4 disks).

> 2. I already have a relatively new 320Gb SATA drive in a caddy that I
> currently used through USB for my data. I would like this to be one half of
> the mirrored RAID, for obvious reasons.
> Questions:
> (a) So if I acquire a PCI/SATA adapter with three or more SATA sockets, and
> plug a new SATAII drive plus my 'old' SATA drive into it, using software
> RAID to manage them, can I expect any obvious problems? (I'm using Debian
> Squeeze, remember.) I understand that unless I am lucky enough to find a
> similarly sized drive, I will lose capacity on the larger of the two (ie
> the new one), but that doesn't particularly bother me.

You don't need to lose capacity.

make a partition on the big disk, that matches the size of a partition
on the small disk, raid those partitions.

then you have the rest over for, unraided use (I often use such
areas for downloads or for things that are in source control, or
git-annex, type stuff, where I know I have copies elsewhere).

Alternatively, you could use the rest for raiding with the SSD.  It you
set the --write-mostly option on the partition on the big slow disk,
then all your reads will come from the SSD.

The other thing I generally do with that sort of RAID setup is use about
twice as many partitions as you really need, so that you can make as
many of them as possible the same size -- that lets you shuffle things
around later more easily.  I then use LVM over the top to stitch it back
together and keep my sanity.

Of course, if btrfs does what it's claimed (not been brave enough to try
it with any data I want back yet) you could get that to deal with all
your data redundancy, and have more security than with software RAID,
and probably rather more flexibility too (although you'd probably want
to upgrade to a kernel from squeeze-backports if you wanted to do that).

Oh, and if you're going from non-RAID to software RAID, be aware of the
option of creating RAIDs with 'failed' disks, and --grow.  You can set
up your new raid on the new disk's partitions, in RAID1 with a
non-existent failed device, copy the data over -- check it's all happy
by booting with just the new drive in, then you can stick the old drive
in (being careful not to boot from it, perhaps by using a live-cd) and
you can then repartition the old drive if you like, and add the
partitions into the (currently degraded) RAIDs running off the new disk.

Cheers, Phil.
|)|  Philip Hands [+44 (0)20 8530 9560]    http://www.hands.com/
|-|  HANDS.COM Ltd.                    http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
Url : http://sclug.org.uk/pipermail/sclug/attachments/20130222/084e1514/attachment.bin 

More information about the Sclug mailing list