[Lustre-discuss] OST errors caused by residual client info?

[Jeff Johnson]

On 12/6/10 3:55 PM, Oleg Drokin wrote:
> Hello!
>
> On Dec 6, 2010, at 6:50 PM, Jeff Johnson wrote:
>> Previous test incarnations of this filesystem were built where ost name
>> was not assigned (e.g.: OSTFFFF) and was assigned upon first mount and
>> connection to the mds. Is it possible that some clients have residual
>> pointers or config data about the previously built file systems?
> If you did not unmount clients from the previous incarnation of the filesystem,
> those clients would still continue to try to contact the servers they know about even
> after the servers themselves go away and are repurposed (since there is no way for the
> client to know about this).
All clients were unmounted but the lustre kernel mods were never 
removed/reloaded nor were the clients rebooted.

Is it odd that this error would occur naming an ost that is not present 
on that oss? Should an oss only report this error about its own ost 
devices? As I said, this particular oss where the error came from only 
has an OST006c and OST006d. It does not have an OST0058 although it may 
have back when the filesystem was made with a simple test csv that did 
not specifically give index numbers as part of the mkfs.lustre process. 
They were named later, randomly, when the osts were first mounted and 
connected to the mds.

Do you think it is possible for a client to retain this information even 
though a umount/mount of the filesystem took place?

--Jeff