On Tue, 10 Oct 2006, Eli Stair wrote:
> I gather this isn't currently possible, but I wonder if it's feasible to make
> it so? This works fine once the array is marked 'clean', and I imagine it's
> simpler to just disallow the bitmap creation until it's in that state. Would
> it be possible to a
[dropped akpm from the Cc: as current discussion isn't directly
relevant to him]
On Tuesday October 10, [EMAIL PROTECTED] wrote:
> On 10/8/06, Neil Brown <[EMAIL PROTECTED]> wrote:
>
> > Is there something really important I have missed?
> No, nothing important jumps out. Just a follow up questio
asured"
region, i.e. the record length is larger than the file size. Iozone
outputs to Excel, but I have also made pdf's of the graphs available.
Note: Openoffice-calc can view the data but it does not support the 3D
surface graphs that Iozone uses.
Excel:
http://prdownloads.sourceforge.n
In testing this some more, I've determined that (always with this
raid10.c patch, sometimes without) the kernel is not recognizing
marked-faulty drives when they're added back to the array. It appears
to be some bit that is flagged and (I assume) normally cleared when that
drive is re-added
On Tue, Oct 10, 2006 at 05:26:25PM -0400, Doug Ledford wrote:
> with garbage that looks like a reiserfs. That's a shortcoming of that
> filesystem and there is no one to blame but Hans Reiser for that.
What do filesystem shortcomings and dead wives have in common?
http://abclocal.go.com/kgo/stor
On Tue, 2006-10-10 at 22:37 +0200, Gabor Gombas wrote:
> You don't get my point. I'm not talking about normal operation, but
> about the case when the filesystem becomes corrupt, and fsck has to glue
> together the pieces. Consider reiserfs:
See my other on list mail about the fallacy of the idea
Thanks Neil,
I just gave this patched module a shot on four systems. So far, I
haven't seen the device number inappropriately increment, though as per
a mail I sent a short while ago that seemed remedied by using the 1.2
superblock, for some reason. However, it appears to have introduced a
On Tue, 2006-10-10 at 23:18 +0400, Sergey Vlasov wrote:
> On Tue, 10 Oct 2006 13:47:56 -0400 Doug Ledford wrote:
>
> [...]
> > So, like my original email said, fsck has no business reading any block
> > that hasn't been written to either by the install or since the install
> > when the filesystem
On Tue, Oct 10, 2006 at 01:47:56PM -0400, Doug Ledford wrote:
> Not at all true. Every filesystem, no matter where it stores its
> metadata blocks, still writes to every single metadata block it
> allocates to initialize that metadata block. The same is true for
> directory blocks...they are cre
Looks like this issue isn't fully resolved after all, after spending
some time trying to get the re-added drive to sync, I've removed and
added it again. This resulted in the previous behaviour I saw, losing
its original numeric position, and becoming "14".
This now looks 100% repeatable, a
I gather this isn't currently possible, but I wonder if it's feasible to
make it so? This works fine once the array is marked 'clean', and I
imagine it's simpler to just disallow the bitmap creation until it's in
that state. Would it be possible to allow creation of the bitmap by
queueing t
On Tue, 10 Oct 2006 13:47:56 -0400 Doug Ledford wrote:
[...]
> So, like my original email said, fsck has no business reading any block
> that hasn't been written to either by the install or since the install
> when the filesystem was filled up more. It certainly does *not* read
> blocks just for
On 10/8/06, Neil Brown <[EMAIL PROTECTED]> wrote:
On Monday September 11, [EMAIL PROTECTED] wrote:
> Neil,
>
> The following patches implement hardware accelerated raid5 for the Intel
> Xscale(r) series of I/O Processors. The MD changes allow stripe
> operations to run outside the spin lock in
On Tue, 2006-10-10 at 11:55 +0200, Gabor Gombas wrote:
> On Mon, Oct 09, 2006 at 12:32:00PM -0400, Doug Ledford wrote:
>
> > You don't really need to. After a clean install, the operating system
> > has no business reading any block it didn't write to during the install
> > unless you are just re
Hi all,
Neil Brown wrote:
> On Tuesday October 10, [EMAIL PROTECTED] wrote:
>
>> Very happy to. Let me know what you'd like me to do.
>>
>
> Cool thanks.
> (snip)
>
I don't know if it's useful information, but I'm encountering the same
problem here, in a totally different situation. I'm
On Mon, Oct 09, 2006 at 12:32:00PM -0400, Doug Ledford wrote:
> You don't really need to. After a clean install, the operating system
> has no business reading any block it didn't write to during the install
> unless you are just reading disk blocks for the fun of it.
What happens if you have a
16 matches
Mail list logo
