[Bugs] [Bug 1181048] lockless lookup cause disk to be kicked out

bugzilla at redhat.com bugzilla at redhat.com
Fri Jan 23 09:41:27 UTC 2015


https://bugzilla.redhat.com/show_bug.cgi?id=1181048



--- Comment #22 from Xavier Hernandez <xhernandez at datalab.es> ---
At point 3, it's possible that a lockless lookup returns inconsistent data,
however in this case inode and fd are not updated (because this inconsistency
might be a false positive). This means that step 5 would send the update to all
three bricks.

The scenario you propose would make all sessions to fail: writes from session 1
and ls from session 2 would fail, and this is not what it's happening.

It could happen, thought I haven't been able to reproduce it yet, that the
lockless lookup made by the second session while a write is being processed on
first session and brick C is down, could return inconsistent data:

1. Brick C is down
2. A write is initiated by session 1 to bricks A and B
3. Brick A completes the write, but brick B is still pending
4. A lockless lookup is initiated by session 2 to bricks A and B
5. Brick A returns file information with size Sa
6. Brick B returns file information with size Sb (Sb < Sa)
7. No data from brick C

In a 3:1 configuration it's required to have at least 2 consistent answers to
return the data. In this case we don't have quorum and an EIO can be returned.
However the next ls would probably succeed. Only an EIO from time to time could
be seen.

Is this what you are seeing ?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=fqzFIqduzZ&a=cc_unsubscribe


More information about the Bugs mailing list