On Fri, Mar 2, 2018 at 9:46 PM, J. Bruce Fields
wrote:
> On Wed, Feb 28, 2018 at 08:15:13AM +0530, Raghavendra Gowdappa wrote:
> > On Wed, Feb 28, 2018 at 2:49 AM, J. Bruce Fields
> > wrote:
> > > That might work. Or, maybe better, take "ESTALE" as a sign that the
> > > parent directory is gone
On Wed, Feb 28, 2018 at 08:15:13AM +0530, Raghavendra Gowdappa wrote:
> On Wed, Feb 28, 2018 at 2:49 AM, J. Bruce Fields
> wrote:
> > That might work. Or, maybe better, take "ESTALE" as a sign that the
> > parent directory is gone and give up on trying to remove further entries
> > from it.
> >
>
On Wed, Feb 28, 2018 at 2:49 AM, J. Bruce Fields
wrote:
> On Mon, Feb 26, 2018 at 11:20:49AM +0530, Raghavendra G wrote:
> > On Fri, Feb 23, 2018 at 6:33 AM, J. Bruce Fields
> > wrote:
> >
> > > On Thu, Feb 22, 2018 at 01:17:58PM +0530, Raghavendra G wrote:
> > > > For a local filesystem, we may
On Mon, Feb 26, 2018 at 11:20:49AM +0530, Raghavendra G wrote:
> On Fri, Feb 23, 2018 at 6:33 AM, J. Bruce Fields
> wrote:
>
> > On Thu, Feb 22, 2018 at 01:17:58PM +0530, Raghavendra G wrote:
> > > For a local filesystem, we may not end up in ESTALE errors. But, when
> > rmdir
> > > is executed f
On Fri, Feb 23, 2018 at 6:33 AM, J. Bruce Fields
wrote:
> On Thu, Feb 22, 2018 at 01:17:58PM +0530, Raghavendra G wrote:
> > On Wed, Oct 11, 2017 at 7:32 PM, J. Bruce Fields
> > wrote:
> >
> > > On Wed, Oct 11, 2017 at 04:11:51PM +0530, Raghavendra G wrote:
> > > > On Thu, Mar 31, 2016 at 1:22 A
On Thu, Feb 22, 2018 at 01:17:58PM +0530, Raghavendra G wrote:
> On Wed, Oct 11, 2017 at 7:32 PM, J. Bruce Fields
> wrote:
>
> > On Wed, Oct 11, 2017 at 04:11:51PM +0530, Raghavendra G wrote:
> > > On Thu, Mar 31, 2016 at 1:22 AM, J. Bruce Fields
> > > wrote:
> > >
> > > > On Mon, Mar 28, 2016 a
On Thu, Feb 22, 2018 at 1:17 PM, Raghavendra G
wrote:
>
>
> On Wed, Oct 11, 2017 at 7:32 PM, J. Bruce Fields
> wrote:
>
>> On Wed, Oct 11, 2017 at 04:11:51PM +0530, Raghavendra G wrote:
>> > On Thu, Mar 31, 2016 at 1:22 AM, J. Bruce Fields
>> > wrote:
>> >
>> > > On Mon, Mar 28, 2016 at 04:21:0
On Wed, Oct 11, 2017 at 7:32 PM, J. Bruce Fields
wrote:
> On Wed, Oct 11, 2017 at 04:11:51PM +0530, Raghavendra G wrote:
> > On Thu, Mar 31, 2016 at 1:22 AM, J. Bruce Fields
> > wrote:
> >
> > > On Mon, Mar 28, 2016 at 04:21:00PM -0400, Vijay Bellur wrote:
> > > > I would prefer to:
> > > >
> >
Hi Bruce,
On 20 October 2017 at 22:22, J. Bruce Fields wrote:
> On Wed, Oct 18, 2017 at 10:19:13AM +0200, Michael Kerrisk (man-pages) wrote:
>> On 10/11/2017 04:02 PM, J. Bruce Fields wrote:
>> > On Wed, Oct 11, 2017 at 04:11:51PM +0530, Raghavendra G wrote:
>> >> On Thu, Mar 31, 2016 at 1:22 AM,
On Mon, Oct 23, 2017 at 05:37:53PM +0200, Michael Kerrisk (man-pages) wrote:
> On 20 October 2017 at 22:22, J. Bruce Fields wrote:
> > The basic issue is that unlike on a local filesystem, NFS can't
> > necessarily keep an unlinked but in-use object around; so attempts to
> > use such may return E
On Wed, Oct 18, 2017 at 10:19:13AM +0200, Michael Kerrisk (man-pages) wrote:
> On 10/11/2017 04:02 PM, J. Bruce Fields wrote:
> > On Wed, Oct 11, 2017 at 04:11:51PM +0530, Raghavendra G wrote:
> >> On Thu, Mar 31, 2016 at 1:22 AM, J. Bruce Fields
> >> wrote:
> >>
> >>> On Mon, Mar 28, 2016 at 04:2
On 10/11/2017 04:02 PM, J. Bruce Fields wrote:
> On Wed, Oct 11, 2017 at 04:11:51PM +0530, Raghavendra G wrote:
>> On Thu, Mar 31, 2016 at 1:22 AM, J. Bruce Fields
>> wrote:
>>
>>> On Mon, Mar 28, 2016 at 04:21:00PM -0400, Vijay Bellur wrote:
I would prefer to:
1. Return ENOENT for
On Wed, Oct 18, 2017 at 12:04:39PM +0530, Raghavendra G wrote:
> On Wed, Oct 11, 2017 at 4:11 PM, Raghavendra G
> wrote:
>
> > We ran into a regression [2][3]. Hence reviving this thread.
> >
> > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1500269
> > [3] https://review.gluster.org/18463
> >
Adding in Eric and Steve.
Ric
On Oct 18, 2017 9:35 AM, "Raghavendra G" wrote:
+Brian Foster
On Wed, Oct 11, 2017 at 4:11 PM, Raghavendra G
wrote:
> We ran into a regression [2][3]. Hence reviving this thread.
>
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1500269
> [3] https://review.g
+Brian Foster
On Wed, Oct 11, 2017 at 4:11 PM, Raghavendra G
wrote:
> We ran into a regression [2][3]. Hence reviving this thread.
>
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1500269
> [3] https://review.gluster.org/18463
>
> On Thu, Mar 31, 2016 at 1:22 AM, J. Bruce Fields
> wrote:
>
>
On Wed, Oct 11, 2017 at 07:26:43AM -0400, Raghavendra Gowdappa wrote:
> Another place to not convert is for those cases where kernel retries the
> operation on seeing an ESTALE.
>
> I guess we need to think through each operation and we cannot ESTALE to
> ENOENT always.
By the way, my advice w
We ran into a regression [2][3]. Hence reviving this thread.
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1500269
[3] https://review.gluster.org/18463
On Thu, Mar 31, 2016 at 1:22 AM, J. Bruce Fields
wrote:
> On Mon, Mar 28, 2016 at 04:21:00PM -0400, Vijay Bellur wrote:
> > On 03/28/2016 09:
quot;Ira Cooper"
>
> Sent: Thursday, March 31, 2016 1:22:46 AM
> Subject: Re: [Gluster-devel] Report ESTALE as ENOENT
>
> On Mon, Mar 28, 2016 at 04:21:00PM -0400, Vijay Bellur wrote:
> > On 03/28/2016 09:34 AM, FNU Raghavendra Manjunath wrote:
> > >
> >
On Wed, Oct 11, 2017 at 04:11:51PM +0530, Raghavendra G wrote:
> On Thu, Mar 31, 2016 at 1:22 AM, J. Bruce Fields
> wrote:
>
> > On Mon, Mar 28, 2016 at 04:21:00PM -0400, Vijay Bellur wrote:
> > > I would prefer to:
> > >
> > > 1. Return ENOENT for all system calls that operate on a path.
> > >
>
On Mon, Mar 28, 2016 at 04:21:00PM -0400, Vijay Bellur wrote:
> On 03/28/2016 09:34 AM, FNU Raghavendra Manjunath wrote:
> >
> >I can understand the concern. But I think instead of generally
> >converting all the ESTALE errors ENOENT, probably we should try to
> >analyze the errors that are generat
uot; mailto:skod...@redhat.com>>
> Cc: "Ira Cooper" mailto:icoo...@redhat.com>>, "Gluster Devel"
mailto:gluster-devel@gluster.org>>
> Sent: Thursday, March 24, 2016 8:11:19 PM
> Subject: Re: [Gluster-devel] Report ESTALE as ENOENT
&g
.openstack.org/show/335506/
>
> Regards,
> -Prashanth Pai
>
> - Original Message -
> > From: "FNU Raghavendra Manjunath"
> > To: "Soumya Koduri"
> > Cc: "Ira Cooper" , "Gluster Devel" <
> gluster-devel@gluster.org>
quot;Soumya Koduri"
> Cc: "Ira Cooper" , "Gluster Devel"
>
> Sent: Thursday, March 24, 2016 8:11:19 PM
> Subject: Re: [Gluster-devel] Report ESTALE as ENOENT
>
>
> I would still prefer not converting all the ESTALE to ENOENT. I think we need
>
I would still prefer not converting all the ESTALE to ENOENT. I think we
need to understand this specific case of parallel rm -rfs getting ESTALE
errors and handle it accordingly.
Regarding, gfapi not honoring the ESTALE errors, I think it would be better
to do revalidates upon getting ESTALE.
Ju
Thanks for the information.
On 03/24/2016 07:34 PM, FNU Raghavendra Manjunath wrote:
Yes. I think the caching example mentioned by Shyam is a good example of
ESTALE error. Also User Serviceable Snapshots (USS) relies heavily on
ESTALE errors. Because the files/directories from the snapshots are
Yes. I think the caching example mentioned by Shyam is a good example of
ESTALE error. Also User Serviceable Snapshots (USS) relies heavily on
ESTALE errors. Because the files/directories from the snapshots are
assigned a virtual gfid on the fly when being looked up. If those inodes
are purged out
On 03/23/2016 12:07 PM, Ravishankar N wrote:
On 03/23/2016 09:16 PM, Soumya Koduri wrote:
If it occurs only when the file/dir is not actually present at the
back-end, shouldn't we fix the server to send ENOENT then?
I never fully understood it here is the answer:
http://review.gluster.org/#/c/6
- Original Message -
> From: "Soumya Koduri"
> To: "Raghavendra Gowdappa"
> Cc: "Poornima Gurusiddaiah" , "Raghavendra Talur"
> , "Shyamsundar Ranganathan"
> , "Vijay Bellur" , "Niels de Vos"
> , "Ira Cooper"
> , "Nithya Balachandran" , "Gluster
> Devel"
> Sent: Wednesday, March 23,
On 03/23/2016 09:16 PM, Soumya Koduri wrote:
If it occurs only when the file/dir is not actually present at the back-end,
shouldn't we fix the server to send ENOENT then?
I never fully understood it here is the answer:
http://review.gluster.org/#/c/6318/
__
Hi Raghavendra,
In [1], its mentioned that "when the inode/gfid is missing, brick report back
as an ESTALE error". Could you please list the possible cases which shall
result in this behavior. If it occurs only when the file/dir is not actually
present at the back-end, shouldn't we fix the serv
30 matches
Mail list logo