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...
>
> --
> Pranith
>
regards,
Raghavendra
--
Pranith
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
