On 7/20/07, Dave Young <[EMAIL PROTECTED]> wrote:
>On 7/20/07, Al Boldi <[EMAIL PROTECTED]> wrote:
> As always, a good friend of mine managed to scratch my partion table by
> cat'ing /dev/full into /dev/sda. I was able to push him out of the way, but
/dev/null ?
withdraw my wrong comment.
> a
On Fri, Jul 20, 2007 at 08:13:03AM +0300, Al Boldi wrote:
> As always, a good friend of mine managed to scratch my partion table by
> cat'ing /dev/full into /dev/sda. I was able to push him out of the way, but
> at least the first 100MB are gone. I can probably live without the first
> partion
On 7/20/07, Willy Tarreau <[EMAIL PROTECTED]> wrote:
On Fri, Jul 20, 2007 at 08:13:03AM +0300, Al Boldi wrote:
> As always, a good friend of mine managed to scratch my partion table by
> cat'ing /dev/full into /dev/sda. I was able to push him out of the way, but
> at least the first 100MB are gon
Al Boldi wrote:
As always, a good friend of mine managed to scratch my partion table by
cat'ing /dev/full into /dev/sda. I was able to push him out of the way, but
at least the first 100MB are gone. I can probably live without the first
partion, but there are many partitions after that, whic
On 7/19/07, Al Boldi <[EMAIL PROTECTED]> wrote:
As always, a good friend of mine managed to scratch my partion table by
cat'ing /dev/full into /dev/sda. I was able to push him out of the way, but
at least the first 100MB are gone. I can probably live without the first
partion, but there are man
On 7/20/07, Al Boldi <[EMAIL PROTECTED]> wrote:
As always, a good friend of mine managed to scratch my partion table by
cat'ing /dev/full into /dev/sda. I was able to push him out of the way, but
/dev/null ?
at least the first 100MB are gone. I can probably live without the first
partion, but
As always, a good friend of mine managed to scratch my partion table by
cat'ing /dev/full into /dev/sda. I was able to push him out of the way, but
at least the first 100MB are gone. I can probably live without the first
partion, but there are many partitions after that, which I hope should
e
On Thursday July 19, [EMAIL PROTECTED] wrote:
> On Fri, 20 Jul 2007 12:14:31 +1000
> Neil Brown <[EMAIL PROTECTED]> wrote:
>
> > What does
> > od -D -j 65536 -N 4 /dev/md1
> > show. This is the size the reiserfs thinks it is using. Multiply by
> > 4 and you should get 77642048 or maybe a l
On Fri, 20 Jul 2007 12:14:31 +1000
Neil Brown <[EMAIL PROTECTED]> wrote:
> What does
> od -D -j 65536 -N 4 /dev/md1
> show. This is the size the reiserfs thinks it is using. Multiply by
> 4 and you should get 77642048 or maybe a little less. If you get
> more, then reiserfs think the devi
On Thursday July 19, [EMAIL PROTECTED] wrote:
> On Thu, 19 Jul 2007 13:54:50 +1000
> Neil Brown <[EMAIL PROTECTED]> wrote:
>
> > The resierfs filesystem is trying to access beyond the end of the
> > raid1 array. Maybe some indexing information in the array is
> > corrupted.
> > Did you recreate t
Per Bill Davidsen's request I have made available a 2.6.22.1 based
kernel with the current raid5 performance changes I have been working
on:
1/ Offload engine acceleration (recently merged for the 2.6.23
development cycle)
2/ Stripe-queue, an evolutionary change to the raid5 queuing model (take4)
On Thu, 19 Jul 2007 13:54:50 +1000
Neil Brown <[EMAIL PROTECTED]> wrote:
> The resierfs filesystem is trying to access beyond the end of the
> raid1 array. Maybe some indexing information in the array is
> corrupted.
> Did you recreate the array (mdadm --create) after changing to the new
> driver
Justin Piszcz wrote:
Any reason you are using 2.6.19-rc5? Why not use 2.6.22.(1)?
I just wanted to try to understand the reason for the problem before
changing to a new kernel. I had not heard that any such problem had
been encountered, though I could have missed the news.
Have you heard
Lars Schimmer wrote:
> Justin Piszcz wrote:
>
> > On Wed, 18 Jul 2007, Rui Santos wrote:
>
> >> Hi,
> >>
> >> I'm getting a strange slow performance behavior on a recently installed
> >> Server. Here are the details:
> >>
> >> Server: Asus AS-TS500-E4A
> >> Board: Asus DSBV-D (
> >>
> http://uk.a
On Thu, 19 Jul 2007, Lars Schimmer wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Justin Piszcz wrote:
On Wed, 18 Jul 2007, Rui Santos wrote:
Hi,
I'm getting a strange slow performance behavior on a recently installed
Server. Here are the details:
Server: Asus AS-TS500-E4A
Board:
On Thu, 19 Jul 2007, J. Hart wrote:
When I configure a 2.6.19-rc5 linux kernel for "built-in" raid support, I do
not get the expected /proc/mdstat entry. I set the following kernel
parameters for this :
CONFIG_MD=Y
BLK_DEV_MD=y
MD_RAID0=y
When I configure the kernel for modular raid supp
When I configure a 2.6.19-rc5 linux kernel for "built-in" raid support,
I do not get the expected /proc/mdstat entry. I set the following
kernel parameters for this :
CONFIG_MD=Y
BLK_DEV_MD=y
MD_RAID0=y
When I configure the kernel for modular raid support in otherwise
identical fashion, I d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Justin Piszcz wrote:
>
>
> On Wed, 18 Jul 2007, Rui Santos wrote:
>
>> Hi,
>>
>> I'm getting a strange slow performance behavior on a recently installed
>> Server. Here are the details:
>>
>> Server: Asus AS-TS500-E4A
>> Board: Asus DSBV-D (
>> http
On Wednesday July 18, [EMAIL PROTECTED] wrote:
> Did the asynchronous write stuff (as it was in fr1) ever get into kernel
> software raid?
Hmmm... what was 'fr1' again??.. asks google.
http://www.it.uc3m.es/ptb/fr1/
Yes, that sound like the 'bitmap' support currently in md.
The bitmap is store
David Shaw wrote:
>> I'm not sure whether this is problem of sata_sil24 or dm layer. Cc'ing
>> linux-raid for help. How much memory do you have? One big difference
>> between ata_piix and sata_sil24 is that sil24 can handle 64bit DMA.
>> Maybe dma mapping or something interacts weirdly with dm t
20 matches
Mail list logo