2:43 p.m.
Why is the expire_time_attr export config parameter not respected when
attributes are being refreshed, I don't see where we check for
expire_time_attr before calling the FSAL getattr. Did I miss it ?
Thanks, Marc.
10:45 p.m.
Hi Daniel,
I am trying to understand the support for expire_time_attr. First there is
this comment in the code
/** Expiration time interval in seconds for attributes. Settable with
Attr_Expiration_Time (should never be set for client export_perms.
*/
int32_t expire_time_attr;
But I see this initialization code:
#define GLOBAL_EXPORT_PERMS_INITIALIZER \
.def.anonymous_uid = ANON_UID, \
.def.anonymous_gid = ANON_GID, \
.def.expire_time_attr = 60, \
My question is in which configuration block you set Attr_Expiration_Time
for export_perms and which block set it for attrlist
Thanks, Marc.
9:12 a.m.
On 3/1/19 11:45 PM, Marc Eshel wrote:
Attr_Expiration_Time is an export parameter, so it can be set in the
Export block or the Export_Defaults block. When a new entry is created
(in mdcache_new_entry()), that value is copied from the export into the
attrlist for that entry. Thereafter, it's referenced directly from the
attrlist.
So, it's only configured on an export, but it's referenced from the
attrlist of the entry itself.
Daniel
11:37 a.m.
Thanks for the information, I still don't know what is this comment
referring to, what is setting client export_perms?
> Attr_Expiration_Time (should never be set for client
export_perms.
Marc.
Daniel Gryniewicz <dang(a)redhat.com> wrote on 03/04/2019 07:12:09 AM:
there is
> > this comment in the code
> >
> > /** Expiration time interval in seconds for attributes. Settable with
> Attr_Expiration_Time (should never be set for client
export_perms.
Attr_Expiration_Time
12:09 p.m.
A client entry has a copy of export_perms in it (named client_perms),
but we don't want expire_time_attr to be configurable in the client
block. To do this, we left expire_time_attr out of CONF_EXPORT_PERMS(),
and it's explicitly added to export_params[] and export_update_params[].
This keeps it from being configured in client_perms.
All this is in support/exports.c
Daniel
On 3/4/19 12:37 PM, Marc Eshel wrote:
12:41 p.m.
Right, and the reason for that is that the expire_time_attr is a property of an MDCACHE
inode. Most of the time those belong to a single export, so setting expire_time_attr per
export will work fine (should an inode actually be shared by multiple exports, and they
have different expire_time_attr, then the expire_time_attr will be set from whichever
export a particular instance of the inode is first accessed via). Having the setting in
the client block would mean the setting would be dependent on whichever client first
accessed the inode...
If we have a per-filesystem config block, that would be a better place for the parameter,
but we don't have such a config block...
Frank
2207
days inactive
2210
days old
6 comments
3 participants
participants (3)
-
Daniel Gryniewicz -
Frank Filz -
Marc Eshel