On Fri, Sep 30, 2016 at 9:13 AM, Raghavendra Gowdappa <rgowd...@redhat.com> 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" <pkara...@redhat.com> > > To: "Shyam Ranganathan" <srang...@redhat.com>, "Raghavendra Gowdappa" < > rgowd...@redhat.com>, "Nithya Balachandran" > > <nbala...@redhat.com> > > Cc: "Gluster Devel" <gluster-devel@gluster.org> > > 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... > > > > > -- > > Pranith > > > > regards, > Raghavendra > -- Pranith
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel