Hi, folks.

We just got a DELL POWEREDGE 2950. So I was tasked with putting
Linux Redhat and dumped our software/packages on it. Contrary to
common sense, I didn't bother reading the manuals that came with te
2950. I went right ahead and installed Redhat server on it, then went
and loaded the backups software/data etc onto it and started having
the team use it.

So what's the problem??? RAID, that's right RAID. I had thought that
it defaulted to RAID-1 when I went into the bios CTRL-R and saw that
it says RAID-1 This is what we wanted it (redudancy) so I left it as
is and installed our stuffs and started using the system. Now two
weeks later I went and tested the RAID1 by pulling out one of the two
drives SAS 73GB that came with the system. Low and behold, teh
remaining drive in teh machine won't boot up. It appears as if it
just sat there this whole time without replicating the content of the
main (boot) drive. So now I am screwed. It would mean I will have to
redo everything over?
On closer look there is a CD that came with the system "Installation &
SErver Management" bootable_cd version 5.2. Was I suppose to
configure RAID-1 using the CD and not just rely on the defaulted
RAID-1 configuration? I checked the bios just now with CTRL-R during
boot up and sure enough it says RAID-1 with two Physical Disks and one
Virtual Disk. So what's wrong? How come it didn't replicate onto
Disk2?

Is there anything I can do to for it to start replicating? Or am I
screw? and have to redo everything? Thanks in advance.

Joseph wrote:
> We just got a DELL POWEREDGE 2950. So I was tasked with putting
> Linux Redhat and dumped our software/packages on it. Contrary to
> common sense, I didn't bother reading the manuals that came with te
> 2950. I went right ahead and installed Redhat server on it, then went
> and loaded the backups software/data etc onto it and started having
> the team use it.

And this has to do with pgsql.performance exactly what?

Anyway, as someone who seems to administrates a PostgreSQL production
box, you sure have a good backup plan. So just call DELL's support, fix
you RAID and restore form backup.

From the DELL site it seems this `PERC 5/i' on board controller
(assuming that's what you have) doesn't even have a BBU. If you don't
plan to post here in a few weeks again about data corruption, go out and
shop a serious controller.

And before you move that box in production, check:

Is my hardware and software setup fsync/fua clean?
Is my backup plan working?


--
Best regards,
Hannes Dorbath

On Sat, Jul 14, 2007 at 10:29:05AM +0200, Hannes Dorbath wrote:
> From the DELL site it seems this `PERC 5/i' on board controller
> (assuming that's what you have) doesn't even have a BBU. If you don't
> plan to post here in a few weeks again about data corruption, go out and
> shop a serious controller.

We have a 2950 with a PERC, and it has a BBU.

/* Steinar */
--
Homepage: http://www.sesse.net/

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

"Hannes Dorbath" <light@theendofthetunnel.de> writes:

> From the DELL site it seems this `PERC 5/i' on board controller
> (assuming that's what you have) doesn't even have a BBU. If you don't
> plan to post here in a few weeks again about data corruption, go out and
> shop a serious controller.

This is a bit of a strange comment. A BBU will improve performance but
Postgres doesn't require one to guarantee data integrity.

If your drives have write caching disabled (ie write-through) and your
controller does write-through caching and you leave fsync=on and
full_page_writes=on which is the default then you shouldn't have any data
integrity issues.

Note that many drives, especially IDE drives ship with write caching enabled
(ie, write-back).

And without a BBU many people are tempted to set fsync=off which improves
performance at the cost of data loss on a system crash or power failure. With
a BBU there's no advantage to fsync=off so that temptation to risk data loss
is removed.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Gregory Stark wrote:
>> From the DELL site it seems this `PERC 5/i' on board controller
>> (assuming that's what you have) doesn't even have a BBU. If you don't
>> plan to post here in a few weeks again about data corruption, go out and
>> shop a serious controller.
>
> This is a bit of a strange comment. A BBU will improve performance but
> Postgres doesn't require one to guarantee data integrity.
>
> If your drives have write caching disabled (ie write-through) and your
> controller does write-through caching and you leave fsync=on and
> full_page_writes=on which is the default then you shouldn't have any data
> integrity issues.

That was my point, controllers without BBU usually leave drive caches
turned on, as with drive caches off performance would be unbearable bad.


--
Best regards,
Hannes Dorbath

On Sat, Jul 14, 2007 at 12:19:51PM +0200, Hannes Dorbath wrote:
> Gregory Stark wrote:
> >> From the DELL site it seems this `PERC 5/i' on board controller
> >> (assuming that's what you have) doesn't even have a BBU. If you don't
> >> plan to post here in a few weeks again about data corruption, go out and
> >> shop a serious controller.
> >
> > This is a bit of a strange comment. A BBU will improve performance but
> > Postgres doesn't require one to guarantee data integrity.
> >
> > If your drives have write caching disabled (ie write-through) and your
> > controller does write-through caching and you leave fsync=on and
> > full_page_writes=on which is the default then you shouldn't have any data
> > integrity issues.
>
> That was my point, controllers without BBU usually leave drive caches
> turned on, as with drive caches off performance would be unbearable bad.

Wow, are you sure about that? I've never heard it before, but that'd be
pretty disturbing if it's true...
--
Jim Nasby decibel@decibel.org
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.3 (FreeBSD)

iD8DBQFGm9zSdO30qud8SkgRAhEQAJ97/IfqiGubwkQVWOOuOtCF9d1nRgCfeNx/
Q0tBg/MmDiD+CrXgb/WLagc=
=xz2+
-----END PGP SIGNATURE-----