|
[12:55:35 PM PDT] wangdi: Andreas: Do you know why we set LUSTRE_RES_ID_SEQ_OFF = 0, and LUSTRE_RES_ID_OID = 1. for resource hash to be more balanced? Historically, we set o_id to res_id[0], o_gr to res_id[1]?
[12:57:18 PM PDT] wangdi: Then if we want get oid or seq from resource id, we need to know it is idif or new FID? but it seems difficult, because we do not know which one is seq. res_id[0] or res_id[1].
[1:00:03 PM PDT] wangdi: sorry, have to run out a while.
[1:01:17 PM PDT] Andreas Dilger: Di: sorry, I didn't notice your message here. two reasons for this:
[1:02:06 PM PDT] Andreas Dilger: CMD branch used [SEQ][OID] for lock resource, and this matches [ino][gen] for old MDS locks
[1:03:01 PM PDT] Andreas Dilger: for OST locks it used [id][gr], which was a very unfortunate choice, since "group" is the larger collection and should have gone first
[1:03:45 PM PDT] Andreas Dilger: in any case, it IS possible to compare if FID is IDIF to use old [id][gr] lock, and new FID should use same [SEQ][OID] locking as MDS
[1:05:20 PM PDT] Andreas Dilger: at some point (several years from now) we could drop old IDIF support by having an upgrade tool that background migrates any files with old IDIF objids to use new OST FIDs
[2:25:05 PM PDT] wangdi: Andreas: if we change ost locks to be [gr][id] on the new client, but old client still use [id][gr], then on the server_side (new one), if we want to check whether it is idif, we need get gr(seq), how do we know it is [0] or [1]?
[2:26:12 PM PDT] wangdi: except we can get other identification(new client or old client) from the connection?
[2:30:21 PM PDT] Andreas Dilger: well, there should never be a new FID with SEQ that is 0 or 1, but rather 0x200000400 or more
[2:30:46 PM PDT] Andreas Dilger: and all of the old objects will have gr = 0, which can never overlap with OID=0 (which is invalid)
[2:31:36 PM PDT] Andreas Dilger: hrmm, I guess this would change the wire protocol for the client, which is not nice
[2:34:02 PM PDT] wangdi: ah, yes, INIT_OID start from 1
[2:35:13 PM PDT] wangdi: so we can always check[1] to be 0 or not. to tell it is a idif or real fid
[2:35:50 PM PDT] wangdi: hmm, probably not change the wire protocol
[2:39:50 PM PDT] Andreas Dilger: sigh, this should have been handled in osc_build_res_name()
[2:40:25 PM PDT] Andreas Dilger: I guess it should be possible if the client connects to the OST with OBD_CONNECT_FID to determine which way the locks should be named
[2:40:40 PM PDT] Andreas Dilger: it would really be good to make them consistent between MDT and OST locks
[2:41:15 PM PDT] wangdi: ok, I will create a ticket.
[2:42:05 PM PDT] Andreas Dilger: it would need some extra complexity on the OST to translate the locks so that they are always consistent internally, even if they are shown differently to clients
[2:42:44 PM PDT] wangdi: ok
[2:45:26 PM PDT] Andreas Dilger: actually, I see that osc_lock_build_res() already handles most of this, just need to fix "if (0)" to check for OBD_CONNECT_FID
[2:47:18 PM PDT] Andreas Dilger: ... and the fact that most places use osc_build_res_name() instead of osc_lock_build_res() to make this actually work
|