[users at i-scream] CPAN Sys::Filesystem on diskless AIX

[David Lee]

On 24/08/12 10:00, Jens Rehsack wrote:
> On 24.08.2012 10:41, David Lee wrote:
>> [...]
>> The module executes:
>>     /usr/sbin/lsvg -Ll `/usr/sbin/lsvg -Lo`
>>
>> This is fine on disk-based systems.  The embedded back-tick command
>> produces one or more lines of genuine output; the surrounding command
>> (with the "-Ll ....") can then process these lines.
>>
>> But on a diskless system the embedded back-tick command produces zero
>> lines of output; the surrounding command expects to see one or more
>> lines, so complains:
>>
>> ----
>> 0516-992 lsvg: Illegal combination of command line options.
>> Usage: lsvg [-o] [[-L] -n PVname]
>>         lsvg [-L] [-i] [-P] [-m] [-M | -l | -p] VGname...
>> Lists the characteristics of a volume group.
>> ----
>>
>> Could you investigate this, please?
>
> I had a defect on my infrastructure machine storing my repository. I'll
> try to get it online again as soon as possible. Please don't hesitate to
> bug me again when I don't react soon.
>
> As I don't have physical access on any AIX box at the moment, it could
> take a bit longer to find an appropriate solution. I'm still unlucky
> with the implementation on AIX.
>
> My favourite implementation uses mntctl as you can see in
> https://github.com/tdb/libstatgrab/tree/jens-mega-patch/
> (https://github.com/tdb/libstatgrab/blob/53baeb77eb27d0296c676cf01a0cd4a5f8fd282f/src/libstatgrab/disk_stats.c)
> line 745..1021.

Thanks, Jens.  Your swift reply is appreciated!  There's no hurry with 
this at present, but it would be nice to keep the topic active.

The main purpose of my email was simply to report what seems to be an 
ugly-looking bug in the "::Aix" module when run on diskless nodes.  (It 
is that the data derived from "lsvg -o" (which is unusual but valid: no 
VGs) isn't handled cleanly by its enclosing "lsvg -l" command.

I'll readily admit that I haven't made any attempt at proposing a fix, 
because of the possibility that a good fix might suggest a somewhat 
wider reworking (as, indeed, your comments about switching to use 
"mntctl" now suggest).


> [...]
>> Local impact and local workaround:
>>
>> It so happens that our local impact of this bug is small at present. Our
>> application would like to determine whether a filename is truly local or
>> is NFS-mounted.  That is why it is calling "Sys::Filesystem". If it is
>> NFS, it will attempt to process it in a slightly different way.  Our
>> local workaround, which is OK for the moment, is simply to avoid
>> "Sys::Filesystem" altogether on this platform and assume all files are
>> truly local.
>
> Well, without local disks, the assumption should be, none truly local,
> shouldn't it?

Actually our application's logic is specifically about NFS. The app runs 
on many platforms, most of which have a mixture of local disk and NFS 
(and perhaps other types).  It is trying to determine for a particular 
user file "is its filesystem specifically NFS", which isn't quite the 
same question as "is it non-local".  (From this perspective, our app 
would classify GPFS, Lustre, ram-filesystem, etc. the same as local: 
more accurately as "non-NFS".)

The (multi-platform) application then attempts a relatively small, 
optional optimisation if the filesystem is specifically NFS: it looks at 
whether Sys::Filesystem's "type()" returns the string "nfs".

But, as mentioned earlier, the main purpose of the email, isn't our 
NFS-isms, but rather about a bug in the module's embedded combination of 
"lsvg" commands.

Best wishes.

-- David Lee