[lustre-discuss] lustre 2.8.0, getattr error rc = -2

[Christopher B Coffey]

Ahh gotcha, thanks!

Chris

—
Christopher Coffey
High-Performance Computing
Northern Arizona University
928-523-1167









On 4/12/16, 7:43 AM, "Patrick Farrell" <paf at cray.com> wrote:

>Christopher,
>
>Andreas is suggesting a Lustre patch - There is no relevant knob to turn
>to control it, it’s just currently a type of message that should always go
>to the console (a warning or emergency message).  You probably *don’t*
>want to suppress those, which is why there’s no easy way to do that, and
>why he’s suggesting a patch to change this message to a different type.
>
>- Patrick
>
>On 4/12/16, 9:32 AM, "lustre-discuss on behalf of Christopher B Coffey"
><lustre-discuss-bounces at lists.lustre.org on behalf of
>Chris.Coffey at nau.edu> wrote:
>
>>Thank you Andreas.  That makes good sense.  I’m sorry, how would you go
>>about quieting that message from the console?  Possibly with sysctl ?  Or
>>maybe with lctl?
>>
>>Best,
>>Chris
>>―
>>Christopher Coffey
>>High-Performance Computing
>>Northern Arizona University
>>928-523-1167
>>
>>
>>
>>
>>
>>
>>
>>
>>On 4/11/16, 3:31 PM, "Dilger, Andreas" <andreas.dilger at intel.com> wrote:
>>
>>>On 2016/04/11, 16:01, "Christopher B Coffey" <Chris.Coffey at nau.edu>
>>>wrote:
>>>
>>>>Hi,
>>>>
>>>>I¹ve upgraded our lustre filesystem from 2.5.3 (server), and 2.6.0
>>>>(client) to 2.8.0 all around.  Things look great.
>>>
>>>Good to hear.
>>>
>>>>  But I am getting these errors on the mds logs:
>>>>
>>>>Apr 11 11:04:02 mds1 kernel: LustreError:
>>>>43984:0:(mdt_handler.c:893:mdt_getattr_internal()) blizzard-MDT0000:
>>>>getattr error for [0x200040406:0xeba3:0x0]: rc = -2
>>>>
>>>>
>>>>But,
>>>>
>>>>lfs fid2path /scratch 0x200040406:0xeba3:0x0
>>>>fid2path: error on FID 0x200040406:0xeba3:0x0: No such file or directory
>>>>
>>>>
>>>>So, the file is really not there.  But, why would the client be
>>>>requesting a file that is not there?  Maybe broken hardlink?  Or what
>>>>else could it be?  A timing issue where the file was deleted in the
>>>>process of being retrieved?  Or does this error message indicate
>>>>something else? Thanks!
>>>
>>>Typically I've seen this when there are two processes running "rm -r" in
>>>the same directory tree, or equivalent (at least one doing "rm", the
>>>other
>>>one could be anything like "find" or "ls -lR" or "rsync" ...).
>>>
>>>This particular message could be quieted from the console
>>>(CERROR->CDEBUG), since it can be generated by a regular user easily and
>>>does not necessarily indicate anything is wrong.  Please file a ticket in
>>>Jira, and if you can also submit a patch that would be even better.
>>>
>>>Cheers, Andreas
>>>-- 
>>>Andreas Dilger
>>>
>>>Lustre Principal Architect
>>>Intel High Performance Data Division
>>>
>>>
>>_______________________________________________
>>lustre-discuss mailing list
>>lustre-discuss at lists.lustre.org
>>http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
>