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

[Oleg Drokin]

Hello!

On Dec 6, 2010, at 7:05 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.

If the clients were unmounted, then there is no information left in the kernel about those now vanished mountpoints.

> 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, 

OSS would report such an error if a client contacted it trying to access an OST not present on this OSS.
This could be because of a client containing some stale information about services because it was not unmounted from previous incarnation of the filesystem
or it could be because there is an failover pair setup that names this OSS as a possible nid for a failover target.

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

If the clients unmounted cleanly, I don't think there is anywhere such info could be stored.

You could go back to the clients sending these requests (identify them by error messages in the logs, they'd complain about error -19 connecting to OSTs) and
see what's wrong with them, what do they have mounted and such.

Bye,
    Oleg