[lustre-discuss] refresh file layout error

[E.S. Rosenberg]

I hope no-one minds me restoring this thread, I just wanted to report back:

After we switched from vanilla kernel-staging lustre to building from
source (lustre 2.8.0 + kernel 4.2.8) this problem ceased to exist, so it
must have been an issue of lustre 2.3.64 (kernel) clients not talking
properly to lustre 2.5.3 servers.

2.8.0 also doesn't play nice with 2.5.3 so we ended up upgrading our
servers too.

Which leads me to 2 questions about current development:
1. Has the mainline kernel seen any progress over the past half year? Will
we ever be able to just use that (at least for clients)?
2. What is the schedule for 2.9.0?

Regards and thanks,
Eli

On Sat, Sep 5, 2015 at 12:08 AM, Patrick Farrell <paf at cray.com> wrote:

> Oops, I'm sorry - this was supposed to be a reply to Amit Kumar's thread.
> Apologies.
> ________________________________________
> From: lustre-discuss [lustre-discuss-bounces at lists.lustre.org] on behalf
> of Patrick Farrell [paf at cray.com]
> Sent: Friday, September 04, 2015 4:07 PM
> To: lustre-discuss at lists.lustre.org; E.S. Rosenberg; Wahl,      Edward
> Subject: Re: [lustre-discuss] refresh file layout error
>
> Martin might know about that short read thing, since his site has a nice
> wiki page on it:
> https://wickie.hlrs.de/platforms/index.php/Lustre_short_read
>
> Technically Lustre is allowed to return fewer bytes than requested, as it
> says on that page.  But it doesn't normally - LU-6389 is a bug where that
> can happen kind of often.  (Again, it's technically allowed as that page
> says...  But it shouldn't really happen in practice, which is why LU-6389
> is a bug.)
>
> So perhaps Gaussian does not retry short reads?  If memory serves, it's
> closed source, so you can't check - but perhaps you could ask the vendor?
> ________________________________________
> From: lustre-discuss [lustre-discuss-bounces at lists.lustre.org] on behalf
> of Martin Hecht [hecht at hlrs.de]
> Sent: Friday, September 04, 2015 8:53 AM
> To: E.S. Rosenberg; Wahl, Edward
> Cc: lustre-discuss at lists.lustre.org
> Subject: Re: [lustre-discuss] refresh file layout error
>
> On 09/03/2015 07:22 AM, E.S. Rosenberg wrote:
> > On Wed, Sep 2, 2015 at 8:47 PM, Wahl, Edward <ewahl at osc.edu> wrote:
> >
> >> That would be my guess here.  Any chance this is across NFS?  Seen that
> a
> >> great deal with this error, it used to cause crashes.
> >>
> > Strictly speaking it is not, but it may be because a part of the path the
> > server 'sees'/'knows' is a symlink to the lustre filesystem which lives
> on
> > nfs...
> >
> Ah, I can remember a problem we had some years ago, when users with
> their $HOME on NFS were accessing many files in directories on lustre
> via symlink. Somehow the NAS box serving the nfs file system didn't
> immediately notice that the files weren't on its own file system and
> repeatedly had to look up in its cache, just to notice that the files
> are somewhere else behind a symlink. If I recall correctly, the problem
> could be avoided by:
> - Either access the file via absolute path, or cd into the directory
> (both via mount point, not (!) via symlink)
> - Or make the symlink an absolute one (I'm not 100% sure, but I believe
> the problem was only with relative links pointing out of the NFS upwards
> across the mountpoint and down again into the lustre file system).
> It could be something similar here. Do you have any chance to access the
> files via absolute path in your setup and web server configuration?
>
> best regards, Martin
>
> _______________________________________________
> lustre-discuss mailing list
> lustre-discuss at lists.lustre.org
> http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/attachments/20160926/24117be8/attachment-0001.htm>