On Thu, 20 Sep 2007 18:27:40 -0700 Dan Williams wrote:
> Signed-off-by: Dan Williams <[EMAIL PROTECTED]>
> ---
Hi Dan,
Looks pretty good and informative. Thanks.
(nits below :)
> Documentation/crypto/async-tx-api.txt | 217
> +
> 1 files changed, 217 insert
Fix dma_wait_for_async_tx to not loop forever in the case where a
dependency chain is longer than two entries. This condition will not
happen with current in-kernel drivers, but fix it for future drivers.
Found-by: Saeed Bishara <[EMAIL PROTECTED]>
Signed-off-by: Dan Williams <[EMAIL PROTECTED]>
ops_complete_biofill tried to avoid calling handle_stripe since all the
state necessary to return read completions is available. However the
process of determining whether more read requests are pending requires
locking the stripe (to block add_stripe_bio from updating dev->toead).
ops_complete_bi
Signed-off-by: Dan Williams <[EMAIL PROTECTED]>
---
Documentation/crypto/async-tx-api.txt | 217 +
1 files changed, 217 insertions(+), 0 deletions(-)
diff --git a/Documentation/crypto/async-tx-api.txt
b/Documentation/crypto/async-tx-api.txt
new file mode 100644
Fix a couple bugs and provide documentation for the async_tx api.
Neil, please 'ack' patch #3.
git://lost.foo-projects.org/~dwillia2/git/iop async-tx-fixes-for-linus
Dan Williams (3):
async_tx: usage documentation and developer notes
async_tx: fix dma_wait_for_async_tx
raid5: f
Michael Tokarev writes:
: Dean S. Messing wrote:
: []
: > [] That's what
: > attracted me to RAID 0 --- which seems to have no downside EXCEPT
: > safety :-).
: >
: > So I'm not sure I'll ever figure out "the right" tuning. I'm at the
: > point of abandoning RAID entirely and just putting the t
Dean S. Messing wrote:
[]
> [] That's what
> attracted me to RAID 0 --- which seems to have no downside EXCEPT
> safety :-).
>
> So I'm not sure I'll ever figure out "the right" tuning. I'm at the
> point of abandoning RAID entirely and just putting the three disks
> together as a big LV and bei
Michal Soltys writes:
: Dean S. Messing wrote:
: >
: > Also (as I asked) what is the downside? From what I have read, random
: > access reads will take a hit. Is this correct?
: >
: > Thanks very much for your help!
: >
: > Dean
: >
:
: Besides bonnie++ you should probably check iozone. It
Bill Davidsen wrote:
: Dean S. Messing wrote:
>
snip
: Do you want to tune it to work well now or work well in the final
: configuration? There is no magic tuning which is best for every use, if
: there was it would be locked in and you couldn't change it.
I want it to work well in the fin
Dean S. Messing wrote:
Also (as I asked) what is the downside? From what I have read, random
access reads will take a hit. Is this correct?
Thanks very much for your help!
Dean
Besides bonnie++ you should probably check iozone. It will allow you to test
very specific settings quite thoro
Bill Davidsen wrote:
> ..
> I'm not clear on what you mean by a "plain disk" followed by a list of
> partitions. If that means putting all your initial data on a single
> disk without RAID protection, that's a far worse idea in my experience
> than splitting arrays across controllers.
It is easiest
Dean S. Messing wrote:
Justin Piszcz wrote:
: One of the 5-10 tuning settings:
:
: blockdev --getra /dev/md0
:
: Try setting it to 4096,8192,16384,32768,65536
:
: blockdev --setra 4096 /dev/md0
:
:
I discovered your January correspondence to the list about this. Yes,
the read-ahead length
Maurice Hilarius wrote:
Hi to all.
I wonder if somebody would care to help me to solve a problem?
I have some servers.
They are running CentOS5
This OS has a limitation where the maximum filesystem size is 8TB.
Each server curr3ently has a AMCC/3WARE 16 port SATA controllers. Total
of 16 port
> I have created a 3 drive RAID5 array, but after each reboot it starts
> degraded with only 1 drive. It also changes the UUID of that drive. I have
> to manualy stop the array and force create it. I've seen similar
> problems in
> the archives but still have not found solution.
I have noticed tha
If/when you experience the hang again please get a trace of all
processes with:
echo t > /proc/sysrq-trigger
Of particular interest is the mke2fs trace; as well as any md threads.
Ok I've played around a bit. I didn't get those long hangs which I
described in my initial mail
but smaller on
On Wed, 19 Sep 2007, Dean S. Messing wrote:
Justin Piszcz wrote:
: Dean Messing wrote:
: > Jusin Piszcz wrote:
: > :
: > I discovered your January correspondence to the list about this. Yes,
: > the read-ahead length makes a dramtic difference---for sequential data
: > reading. However, .
16 matches
Mail list logo
