Re: [HPDD-discuss] nfsd export accounting
----- Original Message -----
I'd guess that the reason you don't see any read stats is
because there's
happen in the context of the ptlrpcd threads. I don't think anyone has ever
looked into this before, so there may be a way to track down where the stats
are supposed to be accounted, and add them to the Lustre read path.
Well it's "nice to have" but not critical functionality I suppose. We do use
NFS exporters to serve a large compute cluster though, and so the more metrics we have for
monitoring this indirect access the better.
As for stats_track_pid that would probably work, though there may be
many
different knfsd threads running at once. It may also be possible to use
stats_track_ppid (parent PID) to get all of the knfsd stats at once?
Well I think the ppid is that of the kthreadd which pretty much includes every kernel
thread. It's a pity that knfsd only tracks operations and not total data in it's
own accounting.
Cheers,
Daire
> On May 16, 2014, at 8:06, "Daire Byrne" <daire(a)dneg.com> wrote:
>
> Hi,
>
> We have a bunch of clients exporting Lustre over NFS and we'd like to graph
> the data read/written by nfsd. With standard NFS servers (with attached
> disks) we can use /proc/{nfsd PID}/io to track the bytes read from disk
> but only write_bytes is updated when exporting a Lustre filesystem. Could
> we use stats_track_pid instead to record the reads for the nfsd processes
> even though it's in the kernel? Is there a good reason why
> /proc/PID/io/read_bytes never gets updated for the nfsd processes? It's
> like nfsd is serving the data directly from the VFS cache so nfsd doesn't
> register a read from Lustre.
>
> These export servers don't exclusively do NFS exporting otherwise we would
> just use the network bytes out.
>
> Regards,
>
> Daire
> _______________________________________________
> HPDD-discuss mailing list
> HPDD-discuss(a)lists.01.org
> https://lists.01.org/mailman/listinfo/hpdd-discuss