[AFS3-std] Fwd: [OpenAFS-devel] RFC: Status returned by vos for pre-attached volumes on demand-attach

Steven Jenkins steven.jenkins@gmail.com
Wed, 22 Jul 2009 10:11:44 -0400


Forwarding here for discussion.

Some notable points:

1- this is about vos reporting for Demand Attached volumes (or other
tools that call the UV_ListVolume RPC and its associated RPCs), not
cache managers, and non-DAFS has no change
2- as noted in Ali's mail, existing/legacy vos will continue to work
as-is and not return the new values, so any tools built on top of vos
can either change (if they want to support the new values) or not.
3- tools or utilities that call the underlying UV_ListVolume RPC
directly will receive the new values.

It seems there are two basic options:

1- use the existing RPCs
2- create new RPCs

Additionally, at least one person has raised a concern about exposing
internal state via vos being too tight of coupling, inhibiting future
work on DAFS (e.g., impacting a possible volume state redesign).  I'd
like suggestions as to how we propose to deal with that.

Apologies to anyone whose comments I've overlooked or misrepresented.

Thanks,
Steven

---------- Forwarded message ----------
From: Alistair Ferguson <Alistair.Ferguson@morganstanley.com>
Date: Wed, Jul 22, 2009 at 3:26 AM
Subject: [OpenAFS-devel] RFC: Status returned by vos for pre-attached
volumes on demand-attach
To: openafs-devel <openafs-devel@openafs.org>


Hi,

We would like to solicit the opinion of the OpenAFS community on what
status vos should return for pre-attached volumes.

The demand-attach file-server introduces a number of volume states
that vos is currently unable to transparently report. Instead, it
simply returns on-line or
off-line. The following comment details when the volume is reported as off-=
line:

=A0 /* Conditions that offline status is based on:
=A0 =A0 =A0volume is unattached state
=A0 =A0 =A0volume state is in (one of several error states)
=A0 =A0 =A0volume not in service
=A0 =A0 =A0volume is not marked as blessed (not on hold)
=A0 =A0 =A0volume in salvage req. state
=A0 =A0 =A0volume needsSalvaged
=A0 =A0 =A0next op would set volume offline
=A0 =A0 =A0next op would not leave volume online (based on several conditio=
ns)
=A0 */

otherwise, it is reported as on-line. =A0The conditions above follow the
general (mis-)perception that volumes with an off-line status are in
error.

The question concerns the status reported for volumes that are
"pre-attached". These are volumes that the file-server hasn't fully
attached because they haven't been accessed (or attached and
subsequently un-attached because they haven't been accessed in a
certain period of time). =A0Currently, these volumes are reported as
on-line, since they aren't in error. However, we believe that we need
more informative reporting for these volumes for a number of reasons:

* strictly speaking, the volumes aren't on-line
* there are a number of ways to determine pre-attached volumes (dump
the file-server state, fssync-debug, ...), but all need to be executed
locally on the file-server
* pre-attached vs attached state is interesting, since it helps
determine exactly what percentage of volumes on a file-server are
actually in use

There are at least four options:
1. expose all underlying states to vos examine
2. expose pre-attached to vos examine
3. convert pre-attached to on-line for vos (the current behavior)
4. convert pre-attached to off-line for vos

Option 3 is currently implemented and is the least desirable.

Our suggestion is that we implement option 1, which will require
exposing the current volume state onto the inUse field in the
FillVolInfo function in the volserver. =A0The vos command would need to
be modified to be aware of the new values, but unmodified vos commands
would report off-line for volumes in a
state other than fully attached.

Note that options 1 and 2 involve a change in behaviour for sites running
demand-attach.

Comments, concerns, agreement?

ali

_______________________________________________
OpenAFS-devel mailing list
OpenAFS-devel@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-devel