----- Original Message ----- > From: "Pranith Kumar Karampuri" <pkarampu@xxxxxxxxxx> > To: "Raghavendra Gowdappa" <rgowdapp@xxxxxxxxxx> > Cc: "Shyam Ranganathan" <srangana@xxxxxxxxxx>, "Nithya Balachandran" <nbalacha@xxxxxxxxxx>, "Gluster Devel" > <gluster-devel@xxxxxxxxxxx> > Sent: Friday, September 30, 2016 10:04:29 AM > Subject: Re: Dht readdir filtering out names > > What if the lower xlators want to set the entry->inode to NULL and clear > the entry->d_stat to force a lookup on the name? i.e. > gfid-split-brain/ia_type mismatches. Didn't get you. If you are using readdirp, as you pointed out dht_readdirp won't work properly if entry->d_stat is zeroed out. So, the entry won't be listed and if it is not listed, we cannot force a lookup on that. > > On Fri, Sep 30, 2016 at 10:00 AM, Raghavendra Gowdappa <rgowdapp@xxxxxxxxxx> > wrote: > > > > > > > ----- Original Message ----- > > > From: "Raghavendra Gowdappa" <rgowdapp@xxxxxxxxxx> > > > To: "Pranith Kumar Karampuri" <pkarampu@xxxxxxxxxx> > > > Cc: "Shyam Ranganathan" <srangana@xxxxxxxxxx>, "Nithya Balachandran" < > > nbalacha@xxxxxxxxxx>, "Gluster Devel" > > > <gluster-devel@xxxxxxxxxxx> > > > Sent: Friday, September 30, 2016 9:58:34 AM > > > Subject: Re: Dht readdir filtering out names > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Pranith Kumar Karampuri" <pkarampu@xxxxxxxxxx> > > > > To: "Raghavendra Gowdappa" <rgowdapp@xxxxxxxxxx> > > > > Cc: "Shyam Ranganathan" <srangana@xxxxxxxxxx>, "Nithya Balachandran" > > > > <nbalacha@xxxxxxxxxx>, "Gluster Devel" > > > > <gluster-devel@xxxxxxxxxxx> > > > > Sent: Friday, September 30, 2016 9:53:44 AM > > > > Subject: Re: Dht readdir filtering out names > > > > > > > > On Fri, Sep 30, 2016 at 9:50 AM, Raghavendra Gowdappa < > > rgowdapp@xxxxxxxxxx> > > > > wrote: > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Pranith Kumar Karampuri" <pkarampu@xxxxxxxxxx> > > > > > > To: "Raghavendra Gowdappa" <rgowdapp@xxxxxxxxxx> > > > > > > Cc: "Shyam Ranganathan" <srangana@xxxxxxxxxx>, "Nithya > > Balachandran" < > > > > > nbalacha@xxxxxxxxxx>, "Gluster Devel" > > > > > > <gluster-devel@xxxxxxxxxxx> > > > > > > Sent: Friday, September 30, 2016 9:15:04 AM > > > > > > Subject: Re: Dht readdir filtering out names > > > > > > > > > > > > On Fri, Sep 30, 2016 at 9:13 AM, Raghavendra Gowdappa < > > > > > rgowdapp@xxxxxxxxxx> > > > > > > wrote: > > > > > > > > > > > > > dht_readdirp_cbk has different behaviour for directories and > > files. > > > > > > > > > > > > > > 1. If file, pick the dentry (passed from subvols as part of > > readdirp > > > > > > > response) if the it corresponds to data file. > > > > > > > 2. If directory pick the dentry if readdirp response is from > > > > > hashed-subvol. > > > > > > > > > > > > > > In all other cases, the dentry is skipped and not passed to > > higher > > > > > > > layers/application. To elaborate, the dentries which are ignored > > are: > > > > > > > 1. dentries corresponding to linkto files. > > > > > > > 2. dentries from non-hashed subvols corresponding to directories. > > > > > > > > > > > > > > Since the behaviour is different for different filesystem > > objects, > > > > > > > dht > > > > > > > needs ia_type to choose its behaviour. > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Pranith Kumar Karampuri" <pkarampu@xxxxxxxxxx> > > > > > > > > To: "Shyam Ranganathan" <srangana@xxxxxxxxxx>, "Raghavendra > > > > > Gowdappa" < > > > > > > > rgowdapp@xxxxxxxxxx>, "Nithya Balachandran" > > > > > > > > <nbalacha@xxxxxxxxxx> > > > > > > > > Cc: "Gluster Devel" <gluster-devel@xxxxxxxxxxx> > > > > > > > > Sent: Friday, September 30, 2016 8:39:28 AM > > > > > > > > Subject: Dht readdir filtering out names > > > > > > > > > > > > > > > > hi, > > > > > > > > In dht_readdirp_cbk() there is a check about skipping > > files > > > > > > > without > > > > > > > > ia_type. Could you help me understand why this check is added? > > > > > > > > There > > > > > are > > > > > > > > times when users have to delete gfid of the entries and trigger > > > > > something > > > > > > > > like 'find . | xargs stat' to heal the gfids. This case would > > fail > > > > > if we > > > > > > > > skip entries without gfid, if the lower xlators don't send stat > > > > > > > information > > > > > > > > for them. > > > > > > > > > > > > > > Probably we can make readdirp_cbk not rely on ia_type and pass > > _all_ > > > > > > > dentries received by subvols to application without filtering. > > > > > > > However > > > > > we > > > > > > > should make this behaviour optional and use this only for > > recovery > > > > > setups. > > > > > > > If we don't rely on ia_type (during non error scenarios), > > > > > > > applications > > > > > end > > > > > > > up seeing duplicate dentries in readdir listing. > > > > > > > > > > > > > > > > > > > That means dht_readdir() gives duplicate entries? As per the code > > it > > > > > seems > > > > > > like it... > > > > > > > > > > No. It follows the filtering logic of "pick dentry only from hashed > > > > > subvol". This logic doesn't need ia_type. Now, that you brought the > > topic > > > > > of dht_readdir, I've another solution for your use case (Basically > > don't > > > > > use readdirp :) ): > > > > > > > > > > 1. mount glusterfs with "--use-readdirp=no" option. > > > > > 2. disable md-cache/stat-prefetch as it converts all readdir calls > > into > > > > > readdirp calls > > > > > > > > > > > > > Probably the ones in dht as well? i.e. use-readdirp option. > > > > > > No. dht doesn't convert a readdir into readdirp. The option you are > > referring > > > to might be "readdir-optimize" which is something different. > > > > Sorry. I was wrong. There is an option in dht too, to force using > > readdirp. As you said, we should disable that too. > > > > > > > > > > > > > > > > > > > > > > > Use this only for recovery setups :). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Pranith > > > > > > > > > > > > > > > > > > > > > > regards, > > > > > > > Raghavendra > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Pranith > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Pranith > > > > > > > > > > > > > -- > Pranith > _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
