12:17 p.m.
The other issue I saw with objects lying around even after the
corresponding export is deleted is when the export is created again
with same attributes.
We start getting cache hits for the old objects. The "struct
fsal_filesystem *fs" for these objects is now pointing to the fs which
we already freed in vfs_unexport_filesystems by calling
release_posix_file_system()
On Sun, Mar 15, 2020 at 10:09 PM Ashish Sangwan
<ashishsangwan2(a)gmail.com> wrote:
>
> Hi Daniel,
>
> It looks like mdcache_lru_cleanup_try_push() can be improved for the
> cases when there are ops executing parallely with an unexport request.
> In this case mdcache_lru_cleanup_try_push() is not able to drop the
> sentinel ref and mark the entry for cleanup. This is because one extra
> ref is taken by the op which is currently executing. The total number
> of refs are > 2.
>
> Once the current op execution finishes (after the execution of
> mdcache_unexport()) the sentinel ref remains and the entry is also not
> marked for cleanup even though no export is referring to it
> (entry->first_export_id == -1).
> Is it possible to modify mdcache_lru_cleanup_try_push() such that even
> if the refcnt is > 2 but if the entry->first_export_id == -1 (the
> current export which is going away was the only one referring to this
> entry), we should drop the sentinel ref and mark the entry for
> cleanup? This will ensure we cleanup the entries when the current op
> does put_ref and these are reused faster than other mdcache entries
> which are actually pointing to valid exports.
>
> Thanks,
> Ashish