On 2/16/2017 6:48 PM, James Sewell wrote:
Sadly this is for a customer who has 3000 of these in the field, the
raid controller is on the motherboard.
if thats the usual Intel "Matrix" raid, thats not actually a raid
controller. its intel sata in fake raid mode, the raid is entirely done
Sadly this is for a customer who has 3000 of these in the field, the raid
controller is on the motherboard.
At least they know where to point the finger now!
Cheers,
James Sewell,
PostgreSQL Team Lead / Solutions Architect
Suite 112, Jones Bay Wharf, 26-32 Pirrama Road, Pyrmont NSW 2009
*P
On Tue, Feb 14, 2017 at 7:23 PM, James Sewell
wrote:
> OK,
>
> So with some help from the IRC channel (thanks macdice and JanniCash)
> it's come to light that my RAID1 comprised of 2 * 7200RPM disks is
> reporting ~500 ops/sec in pg_test_fsync.
>
> This is higher than
OK,
So with some help from the IRC channel (thanks macdice and JanniCash) it's
come to light that my RAID1 comprised of 2 * 7200RPM disks is reporting
~500 ops/sec in pg_test_fsync.
This is higher than the ~120 ops/sec which you would expect from 720RPM
disks - therefore something is lying.
That's the plan, but it's essentially a client managed embedded database so
small steps needed. If I can prove it's the hardware first that would be
preferable.
It looks like diskcheck.pl doesn't work on Windows (no IO::Handle::sync) -
does anybody know of an alternative testkit. A C one would be
On Tue, Feb 14, 2017 at 5:21 AM, James Sewell
wrote:
> Hello All,
>
> I am working with a client who is facing issues with database corruption
> after a physical hard power off (the machines are at remote sites, this
> could be a power outage or user error).
>
> They
On Mon, Feb 13, 2017 at 9:41 PM, Scott Marlowe wrote:
> On Mon, Feb 13, 2017 at 9:21 PM, James Sewell
> wrote:
>>
>> Hello All,
>>
>> I am working with a client who is facing issues with database corruption
>> after a physical hard power off
On Mon, Feb 13, 2017 at 9:21 PM, James Sewell wrote:
>
> Hello All,
>
> I am working with a client who is facing issues with database corruption
> after a physical hard power off (the machines are at remote sites, this could
> be a power outage or user error).
>
>
Hello All,
I am working with a client who is facing issues with database corruption
after a physical hard power off (the machines are at remote sites, this
could be a power outage or user error).
They have an environment made up of many of the following consumer grade
stand alone machines:
-