Lustre devel - Jan 2007 - [Bug 9977] lvbo_init failed for resource for missing objects.

Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
https://bugzilla.lustre.org/show_bug.cgi?id=9977



it seems the last patch has some defects:

1. filter_precreate() 
if (fo_destroy_in_progress) lost "rc = -EAGAIN;" when was moved
below in the code. looks like a bug.

2. if there is no object on ost, filter_lvbo_init() does not initialize
lvb, just sets enoent into lbv->blocks. after that object may be created
in several cases: filter_truncate, filter_preprw_write and ost_create.
whereas first 2 update lvb (filter_lbvo_update), ost_create does not do it.
the following glimpse calls ldlm_handle_enqueue()/filter_intent_policy()
and updates lvb only if there are PW locks after lvb size, i.e. does not
update lvb in other cases, thus it seems glimpse may return wrong data.

3. another problem with ost_create, if a client has a lock over a
non-existent object, an ost_create happens, lock is not cancelled, thus
client will not go to ost to update the object metadata, in particular
on the next glimpse client will still think there is no object.

4. why do we need both OST_LVB_ERR_INIT и OST_LVB_ERR_MASK?
MASK seems to be enough.

Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
https://bugzilla.lustre.org/show_bug.cgi?id=9977



Created an attachment (id=9337)
Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
 --> (https://bugzilla.lustre.org/attachment.cgi?id=9337&action=view)
Fixes after Vitaly''s CODEINSP.

Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
https://bugzilla.lustre.org/show_bug.cgi?id=9977

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #9337|review?(vitaly@clusterfs.com|review-
               Flag|)                           |


(From update of attachment 9337)
1. ldlm_cli_cancel_unused() cancels unused on the resource extent locks.

what is needed is cancel conflict extent locks given to clients and
to not allow to take another lock until object is created and its lvb
data are updated. first of all you need to take a write lock:

res_id = { .name = { oa->o_id } };
policy = { .l_extent = {0, OBD_OBJECT_EOF } };
flags = 0;
rc = ldlm_cli_enqueue_local(obd->obd_namespace, res_id, LDLM_EXTENT, 
				    &policy, LCK_PW, &flags, ldlm_blocking_ast, 
				    ldlm_completion_ast, NULL, NULL, 0, NULL, 
				    &lockh);

re-create objects, update lvb data and only then drop the lock:

ldlm_lock_decref(&lockh, LCK_PW);

be sure the lock is taken for ost_create only, others already have a lock.

2. OST_LVB_ERR_INIT seems to be needed indeed because the return
code is negative, i.e. because ((MASK + rc) & MASK) != MASK.
please put INIT back and add a comment why INIT is needed.

Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
https://bugzilla.lustre.org/show_bug.cgi?id=9977

           What    |Removed                     |Added
----------------------------------------------------------------------------
Attachment #9337 is|0                           |1
           obsolete|                            |


Created an attachment (id=9389)
Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
 --> (https://bugzilla.lustre.org/attachment.cgi?id=9389&action=view)
Fixes after vitaly&green''s codeinsp.

Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
https://bugzilla.lustre.org/show_bug.cgi?id=9977

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #9389|review?(vitaly@clusterfs.com|review-
               Flag|)                           |


(From update of attachment 9389)
1. changes in llite should be propagated to liblustre too.

2. as a result of getting an error from ll_glimpse_size when
an object is absent, ll_file_read will always return an
error when we read beyond the file end. It happens even if
we read from the existent object. This does not look
semantically correct.

Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
https://bugzilla.lustre.org/show_bug.cgi?id=9977


> 2. as a result of getting an error from ll_glimpse_size when
> an object is absent, ll_file_read will always return an
> error when we read beyond the file end. It happens even if
> we read from the existent object. This does not look
> semantically correct.
After talk to Andreas, this is considered acceptable. The reads
within the file size returns the data from the existent object,
and reads beyond EOF can return ENOENT.