On 12 Sep 2019, at 9:25, Trond Myklebust wrote:
> On Thu, 2019-09-12 at 09:13 -0400, J. Bruce Fields wrote:
>> (Unless I'm missing something. I haven't looked at this code in a
>> while. Though it was problem me that wrote it originally--apologies
>> for
>> that)
>>
>
> The function itself i
On Thu, 2019-09-12 at 09:13 -0400, J. Bruce Fields wrote:
> (Unless I'm missing something. I haven't looked at this code in a
> while. Though it was problem me that wrote it originally--apologies
> for
> that)
>
The function itself is fine. It was just the name I'm objecting to,
since we're
On Thu, 2019-09-12 at 09:08 -0400, Benjamin Coddington wrote:
> On 12 Sep 2019, at 8:53, Trond Myklebust wrote:
> > Let's please just scrap this function and rewrite it as a generic
> > function for reading the MIC. It clearly is not a generic function
> > for
> > reading arbitrary netobjs, and mod
On Thu, Sep 12, 2019 at 09:08:51AM -0400, Benjamin Coddington wrote:
>
> On 12 Sep 2019, at 8:53, Trond Myklebust wrote:
> > Let's please just scrap this function and rewrite it as a generic
> > function for reading the MIC. It clearly is not a generic function for
> > reading arbitrary netobjs, a
On 12 Sep 2019, at 8:53, Trond Myklebust wrote:
> Let's please just scrap this function and rewrite it as a generic
> function for reading the MIC. It clearly is not a generic function for
> reading arbitrary netobjs, and modifications like the above just make
> the misnomer painfully obvious.
>
On Thu, 2019-09-12 at 08:29 -0400, Benjamin Coddington wrote:
> On 11 Sep 2019, at 13:54, Chuck Lever wrote:
>
> > > On Sep 11, 2019, at 1:50 PM, Benjamin Coddington
> > > wrote:
> > >
> > > On 11 Sep 2019, at 13:40, Benjamin Coddington wrote:
> > >
> > > > On 11 Sep 2019, at 13:29, Chuck Leve
On 11 Sep 2019, at 13:54, Chuck Lever wrote:
On Sep 11, 2019, at 1:50 PM, Benjamin Coddington
wrote:
On 11 Sep 2019, at 13:40, Benjamin Coddington wrote:
On 11 Sep 2019, at 13:29, Chuck Lever wrote:
On Sep 11, 2019, at 1:26 PM, Benjamin Coddington
wrote:
On 11 Sep 2019, at 12:39, Chuc
On 11 Sep 2019, at 13:43, Chuck Lever wrote:
On Sep 11, 2019, at 1:40 PM, Benjamin Coddington
wrote:
On 11 Sep 2019, at 13:29, Chuck Lever wrote:
On Sep 11, 2019, at 1:26 PM, Benjamin Coddington
wrote:
On 11 Sep 2019, at 12:39, Chuck Lever wrote:
On Sep 11, 2019, at 12:25 PM, Benjamin
> On Sep 11, 2019, at 1:50 PM, Benjamin Coddington wrote:
>
> On 11 Sep 2019, at 13:40, Benjamin Coddington wrote:
>
>> On 11 Sep 2019, at 13:29, Chuck Lever wrote:
>>
On Sep 11, 2019, at 1:26 PM, Benjamin Coddington
wrote:
On 11 Sep 2019, at 12:39, Chuck Lever w
On 11 Sep 2019, at 13:40, Benjamin Coddington wrote:
On 11 Sep 2019, at 13:29, Chuck Lever wrote:
On Sep 11, 2019, at 1:26 PM, Benjamin Coddington
wrote:
On 11 Sep 2019, at 12:39, Chuck Lever wrote:
On Sep 11, 2019, at 12:25 PM, Benjamin Coddington
wrote:
Instead, I think we want to
> On Sep 11, 2019, at 1:40 PM, Benjamin Coddington wrote:
>
> On 11 Sep 2019, at 13:29, Chuck Lever wrote:
>
>>> On Sep 11, 2019, at 1:26 PM, Benjamin Coddington
>>> wrote:
>>>
>>>
>>> On 11 Sep 2019, at 12:39, Chuck Lever wrote:
>>>
> On Sep 11, 2019, at 12:25 PM, Benjamin Coddingto
On 11 Sep 2019, at 13:29, Chuck Lever wrote:
On Sep 11, 2019, at 1:26 PM, Benjamin Coddington
wrote:
On 11 Sep 2019, at 12:39, Chuck Lever wrote:
On Sep 11, 2019, at 12:25 PM, Benjamin Coddington
wrote:
Instead, I think we want to make sure the mic falls squarely into
the tail
every
> On Sep 11, 2019, at 1:26 PM, Benjamin Coddington wrote:
>
>
> On 11 Sep 2019, at 12:39, Chuck Lever wrote:
>
>>> On Sep 11, 2019, at 12:25 PM, Benjamin Coddington
>>> wrote:
>>>
>
>>> Instead, I think we want to make sure the mic falls squarely into the tail
>>> every time.
>>
>> I'm
On 11 Sep 2019, at 13:26, Benjamin Coddington wrote:
On 11 Sep 2019, at 12:39, Chuck Lever wrote:
On Sep 11, 2019, at 12:25 PM, Benjamin Coddington
wrote:
Instead, I think we want to make sure the mic falls squarely into
the tail
every time.
I'm not clear how you could do that. The
On 11 Sep 2019, at 12:39, Chuck Lever wrote:
On Sep 11, 2019, at 12:25 PM, Benjamin Coddington
wrote:
Instead, I think we want to make sure the mic falls squarely into the
tail
every time.
I'm not clear how you could do that. The length of the page data is
not
known to the client bef
> On Sep 11, 2019, at 12:25 PM, Benjamin Coddington wrote:
>
> On 6 Sep 2019, at 16:50, Chuck Lever wrote:
>
>>> On Sep 6, 2019, at 4:47 PM, Jason L Tibbitts III wrote:
>>>
"JBF" == J Bruce Fields writes:
>>>
>>> JBF> Those readdir changes were client-side, right? Based on that
On 6 Sep 2019, at 16:50, Chuck Lever wrote:
On Sep 6, 2019, at 4:47 PM, Jason L Tibbitts III
wrote:
"JBF" == J Bruce Fields writes:
JBF> Those readdir changes were client-side, right? Based on that
I'd
JBF> been assuming a client bug, but maybe it'd be worth getting a
full
JBF> packet
> On Sep 8, 2019, at 12:47 PM, Trond Myklebust wrote:
>
> On Sun, 2019-09-08 at 11:48 -0400, Chuck Lever wrote:
>>> On Sep 8, 2019, at 11:19 AM, Trond Myklebust <
>>> tron...@hammerspace.com> wrote:
>>>
>>> On Sun, 2019-09-08 at 07:39 -0400, Benjamin Coddington wrote:
On 6 Sep 2019, at 1
On Sun, 2019-09-08 at 11:48 -0400, Chuck Lever wrote:
> > On Sep 8, 2019, at 11:19 AM, Trond Myklebust <
> > tron...@hammerspace.com> wrote:
> >
> > On Sun, 2019-09-08 at 07:39 -0400, Benjamin Coddington wrote:
> > > On 6 Sep 2019, at 16:50, Chuck Lever wrote:
> > >
> > > > > On Sep 6, 2019, at 4
> On Sep 8, 2019, at 11:19 AM, Trond Myklebust wrote:
>
> On Sun, 2019-09-08 at 07:39 -0400, Benjamin Coddington wrote:
>> On 6 Sep 2019, at 16:50, Chuck Lever wrote:
>>
On Sep 6, 2019, at 4:47 PM, Jason L Tibbitts III <
ti...@math.uh.edu>
wrote:
> "JBF" == J Bru
On Sun, 2019-09-08 at 07:39 -0400, Benjamin Coddington wrote:
> On 6 Sep 2019, at 16:50, Chuck Lever wrote:
>
> > > On Sep 6, 2019, at 4:47 PM, Jason L Tibbitts III <
> > > ti...@math.uh.edu>
> > > wrote:
> > >
> > > > > > > > "JBF" == J Bruce Fields writes:
> > >
> > > JBF> Those readdir chan
On 6 Sep 2019, at 16:50, Chuck Lever wrote:
On Sep 6, 2019, at 4:47 PM, Jason L Tibbitts III
wrote:
"JBF" == J Bruce Fields writes:
JBF> Those readdir changes were client-side, right? Based on that
I'd
JBF> been assuming a client bug, but maybe it'd be worth getting a
full
JBF> packet
> On Sep 6, 2019, at 4:47 PM, Jason L Tibbitts III wrote:
>
>> "JBF" == J Bruce Fields writes:
>
> JBF> Those readdir changes were client-side, right? Based on that I'd
> JBF> been assuming a client bug, but maybe it'd be worth getting a full
> JBF> packet capture of the readdir reply t
> "JBF" == J Bruce Fields writes:
JBF> Those readdir changes were client-side, right? Based on that I'd
JBF> been assuming a client bug, but maybe it'd be worth getting a full
JBF> packet capture of the readdir reply to make sure it's legit.
I have been working with bcodding on IRC for the
On Tue, Sep 03, 2019 at 08:50:39PM -0500, Jason L Tibbitts III wrote:
> I asked the XFS folks who mentioned that the issues with 64 bit inodes
> are old, constrained to larger filesystems than what I'm using, not an
> issue with nfsv4, and not present on anything but 32bit clients with old
> usersp
I asked the XFS folks who mentioned that the issues with 64 bit inodes
are old, constrained to larger filesystems than what I'm using, not an
issue with nfsv4, and not present on anything but 32bit clients with old
userspace.
In any case, I have been experimenting a bit and somehow the issue seems
Am Dienstag, 3. September 2019, 14:06:33 schrieb Jason L Tibbitts III:
> > "WW" == Wolfgang Walter writes:
> WW> What filesystem do you use on the server? xfs?
>
> Yeah, it's XFS.
>
> WW> If yes, does it use 64bit inodes (or started to use them)?
>
> These filesystems aren't super old, and
On Sep 3, 2019, at 3:06 PM, Jason L Tibbitts III wrote:
>> "WW" == Wolfgang Walter writes:
>
> WW> What filesystem do you use on the server? xfs?
>
> Yeah, it's XFS.
>
> WW> If yes, does it use 64bit inodes (or started to use them)?
>
> These filesystems aren't super old, and were all
> "WW" == Wolfgang Walter writes:
WW> What filesystem do you use on the server? xfs?
Yeah, it's XFS.
WW> If yes, does it use 64bit inodes (or started to use them)?
These filesystems aren't super old, and were all created with the
default RHEL7 options. I'm not sure how to check that 64 bi
Am Dienstag, 3. September 2019, 10:49:48 schrieb Jason L Tibbitts III:
> > "JLT" == Jason L Tibbitts writes:
> JLT> Certainly a server reboot, or maybe even just
> JLT> unmounting and remounting the filesystem or copying the data to
> JLT> another filesystem would tell me that. In any case, a
> "JLT" == Jason L Tibbitts writes:
JLT> Certainly a server reboot, or maybe even just
JLT> unmounting and remounting the filesystem or copying the data to
JLT> another filesystem would tell me that. In any case, as soon as I
JLT> am able to mess with that server, I'll know more.
Rebooting
On Wed, Aug 28, 2019 at 01:29:00PM -0500, Jason L Tibbitts III wrote:
> If I had any idea how to do that, I happily would. I'm certainly
> willing to learn. At least I can run strace to see where ls bombs:
Somewhat of a caveman, I might start at the code for getdents, sprinkle
printk's around un
> "BF" == J Bruce Fields writes:
BF> Looks like that's db531db951f950b8 upstream. (Do you know if it's
BF> reproduceable upstream as well?)
Yes, it's reproducible up in the 5.3.0 RCs as well.
However, while trying to do some further bisecting I ran into an odd
problem. Now kernels which w
On Thu, Aug 22, 2019 at 02:39:26PM -0500, Jason L Tibbitts III wrote:
> I now have another user reporting the same failure of readdir on a long
> directory which showed up in 5.1.20 and was traced to
> 3536b79ba75ba44b9ac1a9f1634f2e833bbb735c. I'm not sure what to do to
> get more traction besides
I now have another user reporting the same failure of readdir on a long
directory which showed up in 5.1.20 and was traced to
3536b79ba75ba44b9ac1a9f1634f2e833bbb735c. I'm not sure what to do to
get more traction besides reposting and adding some addresses to the CC
list. If there is any informat
35 matches
Mail list logo
