staging: lustre: lov: new pattern flag for partially repaired file
When the layout LFSCK repairs orphan OST-object, if the parent MDT-object was lost, then it will re-create the MDT-object and regenerate the LOV EA and fill the target LOV EA slot with the orphan information, and fill other slots with zero (LOV hole); if related LOV EA slot is invalid or hole, then it will refill the target LOV EA slot; if the target slot exceeds current LOV EA tail, then extend the LOV EA, and fill the gaps as zero. Some of the LOV EA holes may cannot be re-filled finally because of lost some OST-objects. And even if they can be re-filled, but there are still some possible race accessings from client before the re-filling. If the client access the LOV EA with hole(s), it may cause some strange behaviour, such as trigger LBUG()/LASSERT() on the client. So we will make the client to be aware of the LOV EA is incomplete. We introduce a new LOV EA pattern flag LOV_PATTERN_F_HOLE for that: any time when the LFSCK repairs the LOV EA with hole(s), the LOV EA will be marked as LOV_PATTERN_F_HOLE; when all the holes in the LOV EA are refilled, the LOV_PATTERN_F_HOLE will be dropped. For a new client, it recongizes the pattern flag LOV_PATTERN_F_HOLE, then it can permit/forbid some opertions on the file with LOV holes: 1) Normal read/write the file with LOV EA hole is permitted, but the application will get EIO error when read data from the dummy slot or write data to the dummy slot. 2) The users can dump the recovered data via some common read tools, such as "dd conv=sync,noerror". 3) Append data to the file which has LOV EA hole will get EIO failure. 4) Other operations will skip the LOV EA hole(s), and will not get failures, such as {s,g}etattr, {s,g}getxattr, stat, chown/chgrp, chmod, touch, unlink, and so on. For an old client, since it will not recognize the new pattern flag LOV_PATTERN_F_HOLE. So the LOV EA with hole will be dicarded with failure, but it will not cause the client to be crashed. Signed-off-by: Fan Yong <fan.yong@intel.com> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4675 Reviewed-on: http://review.whamcloud.com/10042Reviewed-by: Andreas Dilger <andreas.dilger@intel.com> Reviewed-by: Alex Zhuravlev <alexey.zhuravlev@intel.com> Reviewed-by: Oleg Drokin <oleg.drokin@intel.com> Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Showing
Please register or sign in to comment