1 |
I also have to concur with the below message. Adding old outdated hardware |
2 |
to a production server not only creates a bottleneck in performance but |
3 |
could cost you in the event the hardware fails whether it is in /tmp, |
4 |
/var/tmp, or whatever path you destin it to be. The best place for the |
5 |
drives are in the trash can, not in a production server. |
6 |
|
7 |
Brian... |
8 |
|
9 |
----- Original Message ----- |
10 |
From: "stephen white" <steve@×××××××××××××××.au> |
11 |
To: <gentoo-server@g.o> |
12 |
Sent: Saturday, November 08, 2003 9:35 AM |
13 |
Subject: Re: [gentoo-server] Re: Old hdd in server |
14 |
|
15 |
|
16 |
> On Sunday, November 9, 2003, at 02:19 AM, Michael Diederich wrote: |
17 |
> > Thanks for all your replies - /tmp is a very good idea ;-) |
18 |
> |
19 |
> Nobody else said it, so I will... your Linux system can also be |
20 |
> improved by what you don't add, so I would recommend binning the |
21 |
> drives. It's not worth the effort of trying, and it's a false economy |
22 |
> to use them. On /tmp, the machine will die if the drive fails. |
23 |
> |
24 |
> As this is the server mailing list, I'll also point out that adding odd |
25 |
> bits and pieces of hardware to your machines makes groups of servers |
26 |
> more difficult to manage. You should be working towards standardised |
27 |
> machines to minimise the number of hardware profiles you need to |
28 |
> maintain. |
29 |
> |
30 |
> -- |
31 |
> steve@×××××××××××××××.au |
32 |
> |
33 |
> CRICOS Provider Number 00123M |
34 |
> ------------------------------------------------ |
35 |
> This email message is intended only for the addressee(s) |
36 |
> and contains information that may be confidential and/or |
37 |
> copyright. If you are not the intended recipient please |
38 |
> notify the sender by reply email and immediately delete |
39 |
> this email. Use, disclosure or reproduction of this email |
40 |
> by anyone other than the intended recipient(s) is strictly |
41 |
> prohibited. No representation is made that this email or |
42 |
> any attachments are free of viruses. Virus scanning is |
43 |
> recommended and is the responsibility of the recipient. |
44 |
> |
45 |
> |