public inbox for [email protected]  
help / color / mirror / Atom feed
From: Dave Page <[email protected]>
To: [email protected]
To: [email protected]
Subject: Re: developer.pgadmin.org/nagios.pgadmin.org - Disk failure
Date: Sat, 13 May 2006 20:29:21 +0100
Message-ID: <[email protected]> (raw)


-----Original Message-----
From: "Travis Hein"<[email protected]>
Sent: 13/05/06 03:11:53
To: "[email protected]"<[email protected]>
Subject: Re: [pgsql-www] developer.pgadmin.org/nagios.pgadmin.org - Disk failure

> Well, sorry to hear things are funny there, and it is probably not related to 
> my colorful ranting.

:-)

This box has been fine for 18 months or so, so I doubt it's the same issue as yours - still, it's always interesting to hear of others' experiences.

> But I have some space you can borrow to stuff things on, if it is helpful.

Thanks - space isn't a problem though so I should be Ok.

Cheers, Dave.



-----Unmodified Original Message-----
I used to have a pair of old SCSI drives, in software RAID1. I never used 
reiserfs, it was ext2 of the day. It worked great for most of the time, 
except when I did backups, where there was more bus or bulk activity. At 
first I went nuts thinking the scsi tape drive was badly terminated or 
wreaking havoc on the bus, but then I found the same problem happened with 
network backups and backups to IDE drive.
The issue was the kernel scsi card driver was using tag command queueing, but 
one of my drives didn't know what to do with those, whilst the other drive 
did support tag command queueing. I am not a scsi scientist, but my best 
theory was that there was some evil eventual something breaking under the 
high loads because of the different TCQ support, and the software RAID1 
didn't know what to do then.
I never did fix it, i moved to new hardware and abandoned the system all 
together.

Well, sorry to hear things are funny there, and it is probably not related to 
my colorful ranting.

But I have some space you can borrow to stuff things on, if it is helpful.

$>df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             337G  196G  141G  59% /
/dev/sdb1             231G  184G   48G  80% /mnt/backup

/ the 141G is 6 element RAID 5 on ext3, with rsync backup to the /mnt/backup, 
which is a usb drive, but it works :)

let me know if there is anything I can do.


On Friday 12 May 2006 17:47, Dave Page wrote:
> The machine hosting the developer.pgadmin.org and nagios.pgadmin.org
> vservers is currently having serious filesystem problems, which are
> causing disk intensive operations (like rsync, tar) to segfault for
> currently unknown reasons. If you commit to the pgAdmin SVN, please hold
> off for a while, or if you are working on other projects on the machine,
> please don't for now!
>
> If anyone has any idea what might cause ReiserFS to die horribly like
> this, whilst the RAID1 disks don't so much as squeak in the wrong way,
> I'd love to hear it!!
>
> Anyhoo, I have backups, and a replacement machine sitting in the wings
> so I should be able to get things sorted early next week.
>
> Regards, Dave
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to [email protected] so that your
>        message can get through to the mailing list cleanly

-- 
Only those who attempt the absurd can achieve the impossible.

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster




view thread (9+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: developer.pgadmin.org/nagios.pgadmin.org - Disk failure
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox