Hi John,
Thanks for the log. As I looked into the log, I think it has been broken by
the commit:
```
commit 5a6ceb664f07812c351786c1043da71ff5027f8c
Author: Alex Zhuravlev
Date: Mon Sep 28 16:50:15 2015 +0300
LU-7236 ptlrpc: idle connections can disconnect
```
In particular, this
I have sent the log file to you in a separate email.
Note - I read four 1MB blocks, the first two 1MB blocks were cached.
On Fri, May 24, 2019 at 1:01 AM Jinshan Xiong
wrote:
> hmm.. This definitely is not expected. As long as ost 1 is down, it should
> be returned immediately from OSC layer
hmm.. This definitely is not expected. As long as ost 1 is down, it should
be returned immediately from OSC layer and tries to read the 2nd mirror
that is located on ost 7. For the following blocks, it should not even try
ost1 but go to 7 directly.
Would you please collect Lustre log and send it
This is definitely not the intended behavior. Could you please file a ticket
in Jira.
Cheers, Andreas
On May 20, 2019, at 07:20, John Doe wrote:
>
> It turns out that the read eventually finished and was 1/10th of the
> performance that I was expecting.
>
> As ost idx 1 is unavailable,
It turns out that the read eventually finished and was 1/10th of the
performance that I was expecting.
As ost idx 1 is unavailable, the client read has to timeout on ost idx 1
and then will read from ost idx 7. This happens for each 1MB block, as I am
using that as the block size.
Is there a
After mirroring a file , when one mirror is down, any reads from a client
just hangs. Both server and client are running latest 2.12.1-1. Client
waits for ost idx 1 to come back online. I am only unmounting ost idx1 not
ost idx 7.
Has anyone tried this feature?
Thanks,
John.
lfs getstripe