On 05/25/2019 01:51 AM, Song Liu wrote:
On Fri, May 24, 2019 at 3:51 AM Michal Soltys <soltys@xxxxxxxx> wrote:
On 5/23/19 8:09 PM, Song Liu wrote:
Actually, this seems to be unreleated to underlying devices - the culprit seems to be attempting to write to an array after adding journal, without stopping and reassembling it first. Details below.
Thanks for these experiments. Your analysis makes perfect sense.
Do you think you can continue the experiments with the write journal before
this issue got fixed?
I am asking because this is not on the top of my list at this time. If
this is not
blocking other important tests, I would prefer to fix it at a later time.
Thanks,
Song
Yea it's fine. I can help with testing (whenever you sit down to this
issues) as well.
Question though - other than trying to add journal to existing live raid
- is this feature overall safe to use (or are there any other know
issues one should be aware of beforehand) ?
We (Facebook) have done some tests with it. However, we didn't put
it into production. The reason behind this decision was not reliability, but
performance concerns and high level directions. I think Redhat is
evaluating it.
+ Xiao, who might be working on this.
Hi all
It's easy to reproduce this. I enable debug logs and there are some hints
[ 163.227472] handling stripe 0, state=0x2041 cnt=1, pd_idx=2, qd_idx=-1
, check:0, reconstruct:5
[ 163.227472] check 2: state 0x10013 read (null)
write (null) written (null)
[ 163.227473] check 1: state 0x11 read (null) write
(null) written (null)
[ 163.227473] check 0: state 0x1001b read (null)
write (null) written 00000000a1271076
[ 163.227474] locked=2 uptodate=3 to_read=0 to_write=0 failed=0
failed_num=-1,-1
[ 163.227474] Writing block 2
[ 163.227474] Writing block 0
After writing block there is no response. So the I/O hasn't finished yet.
I'll update more information later.
Regards
Xiao
