Bobijam
Could you please look into this one?
Thanks
Peter
Added Alex and Andreas to the watcher list.
here is a short description of the problem: ZFS does not store "." and ".." on a disk, instead it stores parent dnode in znode and generate dots in zfs_readdir():
while (!done) {
uint64_t objnum;
/*
- Special case `.', `..', and `.zfs'.
*/
if (*pos == 0) { (void) strcpy(zap.za_name, "."); zap.za_normalization_conflict = 0; objnum = zp->z_id; }else if (*pos == 1)
{ (void) strcpy(zap.za_name, ".."); zap.za_normalization_conflict = 0; objnum = parent; }else if (*pos == 2 && zfs_show_ctldir(zp)) {
(void) strcpy(zap.za_name, ZFS_CTLDIR_NAME);
zap.za_normalization_conflict = 0;
objnum = ZFSCTL_INO_ROOT;
to comply with ZFS on-disk format we should:
1) initialize parent dnode attribute upon insert("..")
2) do nothing upon insert(".")
3) implement logic similar to zfs_readdir() in iterator methods: osd_zap_it_get(), osd_zap_it_key(), etc
one issue is that parent SA can store upto 8 bytes:
SA_ADD_BULK_ATTR(bulk, cnt, SA_ZPL_PARENT(uos), NULL, &parent, 8);
making it impossible to put dnode and fid in. there are two options here:
1) fetch parent dnode, then fetch LMA from that parent dnode – might be expensive, but usually should be cached
2) store parent fid as an extra EA
also, remember insert("..") can be called few times (in different transactions) as a result of rename.
We already store the parent FID in the linkEA on the object. That allows finding the FID of ".." without searching. FID of "." can be generated from LMA.
LinkEA is being manipulated by MDD and it's not considered as mandatory, AFAIU. for example, we ignore errors related to LinkEA.
We only ignore such errors when there are many links on a regular file. There should always be enough space for a single linkEA on a directory to point to the parent. All ZFS filesystems are 2.x, so they should also have linkEA entries already, unlike upgraded 1.8 filesystems.
I agree MDD creating linkEA might be a bit bothersome, but it is only being read by the OSD code, never modified. If it isn't available, it is always possible to do OI lookup for parent dnode number to find FID?
yes, of course. a minor correction: should be possible to load LMA of specific dnode to find its FID.
http://review.whamcloud.com/4990
not the final version though.. some compatibility with the existing setup is required.
the patch has been updated with the compatibility and additional infrastructure to simulate old setup (where ./.. are stored on a disk).
hmm, this patch provides forward compatibility, but not backward: it does remove ./.. if they are stored on a disk,
but do not add new one (they are generated on demand like ZPL does). with the current master code that will result
in non-existing ./.. and number of consequences.
Christopher, what would be your opinion on this? would you be OK to switch to a new tag and do not go back?
Alex, I think this is the reasonable path forward. The only other option is to start filling in and using the "zp_parent" field, but not delete the "." and ".." entries yet, and that can be done in a separate patch. That would allow migrating to the new code, and only disabling storing of "." and ".." once the first patch is known to be working.
To comment further - I don't think it is necessary to make the extra effort to remove the "." and ".." entries from the on-disk ZAPs, so long as they are filtered out at the readdir level. The legacy filesystems/directories holding "." and ".." will disappear eventually.
not that I'm against this 
just got to think a potential ZPL user can be confused finding two ./..
If thats the worst that we'll see (two sets of . or ..), then I think that is reasonable, and we don't need to jump through hoops to eliminate it. A tool external to lustre to clean it up might be nice. The Sequoia filesystem could live for another 5 years.
Brian, any chance you will have time to inspect the patch in http://review.whamcloud.com/4990?
Brian, would you have time to inspect this patch this week? Thank you!
Landed for 2.4
Still a few fixes for this.
Still http://review.whamcloud.com/5413 to land.
Landed for 2.4
http://review.whamcloud.com/5629 – this patch implements fallback path for lookup(..) when LinkEA is not available.
the only remaining bit to close the ticket is to update parent dnode for regular files on object creation.
http://review.whamcloud.com/#change,5642 – with this patch all the objects should be getting parent dnode attribute initialized properly.
Landed for 2.4
Lowering priority now that first patch has landed.