Hello! Long story. Get some coke.
I'm having an odd problem with using software raid on two Western
Digital disks type WD2500JD-00F (250gb) connected to a Silicon Image
Sil3112 PCI SATA conroller running with Linux 2.6.20, mdadm 2.5.6
When these disks are in a raid1 set, downloading data to the
On Sun, 18 Mar 2007, Sander Smeenk wrote:
Hello! Long story. Get some coke.
I'm having an odd problem with using software raid on two Western
Digital disks type WD2500JD-00F (250gb) connected to a Silicon Image
Sil3112 PCI SATA conroller running with Linux 2.6.20, mdadm 2.5.6
[[ .. snip
In message [EMAIL PROTECTED] you wrote:
But what amazes me is that no media errors can be detected by doing a
write/read check on every sector of the disk with mke2fs, and no data
corruption occurs when moving data to the set locally!
Can anyone shed some light on what i can try next to
Justin Piszcz wrote:
On Sun, 18 Mar 2007, Sander Smeenk wrote:
Hello! Long story. Get some coke.
I'm having an odd problem with using software raid on two Western
Digital disks type WD2500JD-00F (250gb) connected to a Silicon Image
Sil3112 PCI SATA conroller running with Linux 2.6.20,
(relativelySander Smeenk wrote:
Hello! Long story. Get some coke.
I'm having an odd problem with using software raid on two Western
Digital disks type WD2500JD-00F (250gb) connected to a Silicon Image
Sil3112 PCI SATA conroller running with Linux 2.6.20, mdadm 2.5.6
When these disks are in a
Quoting Bill Davidsen ([EMAIL PROTECTED]):
I'm having an odd problem with using software raid on two Western
Digital disks type WD2500JD-00F (250gb) connected to a Silicon Image
Sil3112 PCI SATA conroller running with Linux 2.6.20, mdadm 2.5.6
Your comments below are thoughts on the PATA
Michael Schwarz wrote:
Update:
(For those who've been waiting breathlessly). It hangs at a particular
point in a particular file. In other words, it doesn't depend on the total
number of bytes transfered. Rather, when it reaches a particular point in
a particular file (12267520 bytes into a
I've tried both single and multiple files. The files are not sparse. They
are highly compressed files (mpeg files) that would, to the filesystem, be
nearly random with no repeated patterns or voids.
--
Michael Schwarz
Michael Schwarz wrote:
Update:
(For those who've been waiting
As I suspected, majordomo doesn't like attachments.
I looked through the logs. The only odd thing I see before the read that
hangs is this message:
smartd[3069]: Device: /dev/hda, 1 Currently unreadable (pending) sectors
Which I only see in /var/log/messages because the stack dump blows
On Saturday March 17, [EMAIL PROTECTED] wrote:
Neil Brown wrote:
In-kernel auto-assembly using partition type 0xFD only works for
metadata=0.90. This is deliberate.
Don't use 0xFD partitions. Use mdadm to assemble your array, either
via an initrd or (if it don't hold the root
Quoting Bill Davidsen ([EMAIL PROTECTED]):
Here are several pertinent sections from Neils posts, topic
mismatch_cnt questions
[..]
Does any of that explain why I raise the possibility of the data
changing as the file is written?
Yeah, that helps. But as i understand, these 'differences'
On Sunday March 18, [EMAIL PROTECTED] wrote:
This may be due to a characteristic of RAID1, which I believe Neil
described when discussing check failures in using RAID1 for swap. In
some cases, the data is being written from a user buffer, which is
changing. and the RAID software does two
On Sunday March 18, [EMAIL PROTECTED] wrote:
Hello! Long story. Get some coke.
And a painful story!.
See also http://bugzilla.kernel.org/show_bug.cgi?id=8180
It also involves a Silicon Image PCI/SATA controller, though a
different model.
But then I have an SI PCI SATA controller that has
Just tried in on a stock Ubuntu Edgy install. Same thing. Locks on read.
I've got a dmesg (w/stack trace) file from the ubuntu attempt (it was
clean prior to doing the read) which I will send to Alan and Neil (any
anyone else who asks for it). There were no error messages in dmesg prior
to
On Sunday March 18, [EMAIL PROTECTED] wrote:
cp -rv /mnt/* fs2d2/
At this point, the process hangs. So I ran:
echo t /proc/sysrq-trigger
dmesg dmesg-5-hungread.log
Unfortunate (as you say) the whole trace doesn't fit.
Could you try compiling the kernel with a larger value for
Hello Neil Bill ,
On Sun, 18 Mar 2007, Bill Davidsen wrote:
Neil Brown wrote:
On Saturday March 17, [EMAIL PROTECTED] wrote:
Neil Brown wrote:
In-kernel auto-assembly using partition type 0xFD only works for
metadata=0.90. This is deliberate.
Don't use 0xFD partitions. Use mdadm
More than ever, I am convinced that it is actually a hardware problem, but
I am curious for the opinions of both of you on whether the system
(meaning, I guess, the combination of usb-storage driver and raid) is
really doing the best with what it has.
My last effort was to switch to a different
17 matches
Mail list logo
