lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 21 Oct 2021 11:43:55 -0400
From:   Jeff Layton <jlayton@...nel.org>
To:     Patrick Donnelly <pdonnell@...hat.com>
Cc:     Luís Henriques <lhenriques@...e.de>,
        Ilya Dryomov <idryomov@...il.com>,
        Ceph Development <ceph-devel@...r.kernel.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] ceph: add remote object copy counter to fs client

On Thu, 2021-10-21 at 09:52 -0400, Patrick Donnelly wrote:
> On Wed, Oct 20, 2021 at 12:27 PM Jeff Layton <jlayton@...nel.org> wrote:
> > 
> > On Wed, 2021-10-20 at 15:37 +0100, Luís Henriques wrote:
> > > This counter will keep track of the number of remote object copies done on
> > > copy_file_range syscalls.  This counter will be filesystem per-client, and
> > > can be accessed from the client debugfs directory.
> > > 
> > > Cc: Patrick Donnelly <pdonnell@...hat.com>
> > > Signed-off-by: Luís Henriques <lhenriques@...e.de>
> > > ---
> > > This is an RFC to reply to Patrick's request in [0].  Note that I'm not
> > > 100% sure about the usefulness of this patch, or if this is the best way
> > > to provide the functionality Patrick requested.  Anyway, this is just to
> > > get some feedback, hence the RFC.
> > > 
> > > Cheers,
> > > --
> > > Luís
> > > 
> > > [0] https://github.com/ceph/ceph/pull/42720
> > > 
> > 
> > I think this would be better integrated into the stats infrastructure.
> > 
> > Maybe you could add a new set of "copy" stats to struct
> > ceph_client_metric that tracks the total copy operations done, their
> > size and latency (similar to read and write ops)?
> 
> I think it's a good idea to integrate this into "stats" but I think a
> local debugfs file for some counters is still useful. The "stats"
> module is immature at this time and I'd rather not build any qa tests
> (yet) that rely on it.
> 
> Can we generalize this patch-set to a file named "op_counters" or
> similar and additionally add other OSD ops performed by the kclient?
> 


Tracking this sort of thing is the main purpose of the stats code. I'm
really not keen on adding a whole separate set of files for reporting
this. 

What's the specific problem with relying on the data in debugfs
"metrics" file?


-- 
Jeff Layton <jlayton@...nel.org>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ