16 Apr
2021
16 Apr
'21
10:09 a.m.
On Thu, Apr 15, 2021 at 02:42:17PM -0700, Neha Ojha wrote:
Thank you, Neha!
Here it is: https://tracker.ceph.com/issues/50395
We would like to work on the fix and I am thinking how to approach it.
I think it is not correct that the result of the directory splitting
(partially related to operation) aborts a transaction operation in the
middle with the error code from directory split. And then the
transaction uses this error code to make a decision how to proceed
with the entire transaction (expecting that the error code came from
the operation itself).
Options that I see:
1) Consider the failed directory split not critical to abort the
operation, i.e. ignore the error and proceed.
2) Consider it critical and just abort the osd.
3) replace the error code returned by directory split with some
special error code, so the upper layer (FileStore::_do_transaction)
could make a propriate decision (abort the transaction?).
4) Combination of (1) and (2): depending on the returned code condider
it either non-critical and ignore or critical and abort the osd.
5) Either (1) or (2) depending on a config option.
I would vote for (1) or (4) but I would love to learn what other
people think about the issue and how it could be approached.
Also, it would be nice to know why it was considered that ENODATA
could be ignored in the transaction. I suppose it is because it was
expected that ENODATA could be returned by getxattr only, when the
attribute does not exist, and it was not expected to affect the
transaction result?
--
Mykola Golub
We were seeing
at least two types of such "messy" transactions:
1) On rados writing a new objects, one of the first transaction
operations is OP_TOUCH. It creates the object file, tries to split the
directory, aborts and skips creating the object spill_out attribute
due to this.
2) On rados deleting an object, one of the transactions operations is
OP_COLL_MOVE_RENAME, wich creates a temporary link, which triggers the
directory split and the error, the op is aborted in the middle leaving
the original object file not removed.
So it looks like a bug and could be improved, but the question is if
the upsteam is still interested in improving the filestore in this
area? Should I report it to the tracker?
Please feel free to create a tracker for it. Though we are not
actively developing against filestore, if the fix for this issue isn't
too invasive, I don't see any issues in merging it.