On Thu, Aug 24, 2017 at 2:53 PM, Nithya Balachandran <nbalacha@xxxxxxxxxx> wrote:
It has been a while but iirc snapview client (loaded abt dht/tier etc) had some issues when we ran tiering tests. Rafi might have more info on this - basically it was expecting to find the inode_ctx populated but it was not.
Thanks Nithya. @Rafi, @Raghavendra Bhat, is it possible to take the ownership of,
* Identifying whether the patch in question causes the issue?
* Send a fix or at least evaluate whether a fix is possible.
@Others,
With the motivation of getting some traction on this, Is it ok if we:
* Set a deadline of around 15 days to complete the review (or testing with the patch in question) of respective components and to come up with issues (if any).
* Post the deadline, if there are no open issues, go ahead and merge the patch?
If time is not enough, let us know and we can come up with a reasonable time.
regards,
Raghavendra
On 24 August 2017 at 10:13, Raghavendra G <raghavendra.hg@xxxxxxxxx> wrote:Raghavendraregards,"whether the xlator you are associated with works fine if a non-lookup fop (like open, setattr, stat etc) hits it without a lookup ever being done on that inode"For those not following this thread, the question we need to answer is,features/trashstorage/posixNote that we need to consider xlators on brick stack too. I've added maintainers/peers of xlators on brick stack. Please explicitly ack/nack whether this patch affects your component.For reference, following are the xlators loaded in brick stack
features/changetimerecorder
features/changelog
features/bitrot-stub
features/access-control
features/locks
features/worm
features/read-only
features/leases
features/upcall
performance/io-threads
features/selinux
features/marker
features/barrier
features/index
features/quota
debug/io-stats
performance/decompounder
protocol/serverOn Wed, Aug 23, 2017 at 11:56 AM, Raghavendra Gowdappa <rgowdapp@xxxxxxxxxx> wrote:Thanks Pranith and Ashish for your inputs.
----- Original Message -----
> From: "Pranith Kumar Karampuri" <pkarampu@xxxxxxxxxx>
> To: "Ashish Pandey" <aspandey@xxxxxxxxxx>
> Cc: "Raghavendra Gowdappa" <rgowdapp@xxxxxxxxxx>, "Xavier Hernandez" <xhernandez@xxxxxxxxxx>, "Gluster Devel"
> <gluster-devel@xxxxxxxxxxx>
> Sent: Wednesday, August 23, 2017 11:55:19 AM
> Subject: Re: Need inputs on patch #17985
>
> Raghavendra,
> As Ashish mentioned, there aren't any known problems if upper xlators
> don't send lookups in EC at the moment.
>
> On Wed, Aug 23, 2017 at 9:07 AM, Ashish Pandey <aspandey@xxxxxxxxxx> wrote:
>
> > Raghvendra,
> >
> > I have provided my comment on this patch.
> > I think EC will not have any issue with this approach.
> > However, I would welcome comments from Xavi and Pranith too for any side
> > effects which I may not be able to foresee.
> >
> > Ashish
> >
> > ------------------------------
> > *From: *"Raghavendra Gowdappa" <rgowdapp@xxxxxxxxxx>
> > *To: *"Ashish Pandey" <aspandey@xxxxxxxxxx>
> > *Cc: *"Pranith Kumar Karampuri" <pkarampu@xxxxxxxxxx>, "Xavier Hernandez"
> > <xhernandez@xxxxxxxxxx>, "Gluster Devel" <gluster-devel@xxxxxxxxxxx>
> > *Sent: *Wednesday, August 23, 2017 8:29:48 AM
> > *Subject: *Need inputs on patch #17985
> >
> >
> > Hi Ashish,
> >
> > Following are the blockers for making a decision on whether patch [1] can
> > be merged or not:
> > * Evaluation of dentry operations (like rename etc) in dht
> > * Whether EC works fine if a non-lookup fop (like open(dir), stat, chmod
> > etc) hits EC without a single lookup performed on file/inode
> >
> > Can you please comment on the patch? I'll take care of dht part.
> >
> > [1] https://review.gluster.org/#/c/17985/
> >
> > regards,
> > Raghavendra
> >
> >
>
>
> --
> Pranith
>
http://lists.gluster.org/mailm_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
an/listinfo/gluster-devel
--Raghavendra G
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel
--
Raghavendra G
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
