Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp1047114pxb; Tue, 26 Oct 2021 01:44:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy2TBo/BiyFB9eJgPCdksClGbmlKppiFB3fohxrrVTPuLVNlloP5NXZ1wrt60rzAi+DlP+O X-Received: by 2002:a17:902:cacb:b0:140:4649:6720 with SMTP id y11-20020a170902cacb00b0014046496720mr13503097pld.4.1635237840170; Tue, 26 Oct 2021 01:44:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635237840; cv=none; d=google.com; s=arc-20160816; b=PLPmUQYj9rA/0LgVqg0Y377zco+22L5oxr7sNJN2L4HXTqYHAGzpARVUFPNw7xfc6c HbTeRH18Vd/3TVoudh/l09JlKxnK9uwM3FzqYXQeWLI8o1+XICV3naVkK1rbkhiSoowx /OCHEuEBTZZnBRLaAS/yyKdxR2Jcfg7E0rjQAmYUf52z1t++utKu6THy/BsEJ9W63/CI 6nwjEFf4I0e3Se09Tkw2f/ZV0yL0ZJbxcdiNKsNJG1DLyj+UKFhhiYd8VNntgkUX4muJ Zfbkgc3mMYg//Mro6MQpKi7xzeBMImH8qg6xirv4GFOgc0qwnYFicaMaFvcs7irPtk6A hPxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=bgZfLWj7RPfnAn/W2uAQwfMYaCeUPV0KjyENL3A9vM8=; b=VloACc87h+JT46L0hf+mMMAN/6jU/6OTVaVSzKhgsM67pJ3slyDzHYnakNHY1V7VC+ loODgJJw/9K1/7OcLUSmhjn0OxzSlIx1BPKJq+felSx3wVlyIxcciL3iDgbaifj5SRye NCA6AWOvzUWONzZqqCywK12eVKZixvQmY9csX7DMsIAIdKMYlxvvNg3jevfPHy+wgjtn PlBMNqhSzx/XceNpccUVOJpCK9SqJzmGKlOoduhoCGvr6aYIcxubd18tn5h5p7o/NJCL w7qX/hauTfpn4FusuHXgKiWI0b5Kwd3s7g5AQJyfn9TK7TAe1jENhJHoJ+WizCP6GtvY ZX+A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=fkdGCEu8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o18si35077738pgu.467.2021.10.26.01.43.47; Tue, 26 Oct 2021 01:44:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=fkdGCEu8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234535AbhJZDIf (ORCPT + 99 others); Mon, 25 Oct 2021 23:08:35 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:48354 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231445AbhJZDIe (ORCPT ); Mon, 25 Oct 2021 23:08:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1635217571; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bgZfLWj7RPfnAn/W2uAQwfMYaCeUPV0KjyENL3A9vM8=; b=fkdGCEu8pRJYssAtdP76yliyisG568rrUg74isg1KvbpjY/l+9PcGs1pmO6NMVjol3x886 Dv15Qlqb5+dPn3J1v5i4+WWnns7+0AwPtE+Po4WQI9m2R+nwD+H6amOQAo/l5uIKRhGwFz qyPI0Xv40Dp9lNm963gw8iWNL4qH+pc= Received: from mail-pf1-f198.google.com (mail-pf1-f198.google.com [209.85.210.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-395--xZXXs4OOKaXB2XYYh5-9w-1; Mon, 25 Oct 2021 23:06:09 -0400 X-MC-Unique: -xZXXs4OOKaXB2XYYh5-9w-1 Received: by mail-pf1-f198.google.com with SMTP id y37-20020a056a00182500b0047c102c1ca2so417247pfa.11 for ; Mon, 25 Oct 2021 20:06:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=bgZfLWj7RPfnAn/W2uAQwfMYaCeUPV0KjyENL3A9vM8=; b=ExuF6VcYKFaUHqV2W5z6QQ6KnOgWLF47XRGLymhixRV0zeGJqj/ERNBwPEnOv9RKFa ZpK1ax4DYlFcmYML5P1wkzUlom57yfhb/IZDmWIhiOjzjIKxgFdZ4rbVCFCj3wN0vGxU 3mo/iBNf3gJd14tdZcac8hormS5B8vFbt3iVVqKiYsqrAIu+WXCKwFTZrwtmIaDSOpuE s4nIGzLe3sne+8fwrUZE/g6Lo2bvmEy/zy18jIb/46FeUtRgpN3dJNQVdt3rU0djKTRs 69AC1ThzWA6hadCrIg9mDNJAgQkUvJKnyvq9Cp9073EPDVzuNDhulr7kS54h+t+3Zkrn rITw== X-Gm-Message-State: AOAM533PL6pYOh7ZZDKgWyUqYjbcSDqXTOwDIQApjw0FlF69zHfiu1UX tEUhG9TcbQwexRSa/mo/xk6WfhacETIMoU7sQAv6ViR6uClep9Bg5C4P0D6oJJZ0V0OL9gKYj4w n1cPLgy+GWaB6d219DqhTY4av7BuerbUAveKCs/Ds/k2n6YwRrwt28GJ/Jgr941bRgQEGli+jUg == X-Received: by 2002:a62:7c0b:0:b0:47b:df8d:816 with SMTP id x11-20020a627c0b000000b0047bdf8d0816mr17489654pfc.11.1635217568078; Mon, 25 Oct 2021 20:06:08 -0700 (PDT) X-Received: by 2002:a62:7c0b:0:b0:47b:df8d:816 with SMTP id x11-20020a627c0b000000b0047bdf8d0816mr17489613pfc.11.1635217567561; Mon, 25 Oct 2021 20:06:07 -0700 (PDT) Received: from [10.72.12.93] ([209.132.188.80]) by smtp.gmail.com with ESMTPSA id c4sm23523143pfv.144.2021.10.25.20.06.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 Oct 2021 20:06:06 -0700 (PDT) Subject: Re: [RFC PATCH] ceph: add remote object copy counter to fs client To: Patrick Donnelly , Jeff Layton Cc: =?UTF-8?Q?Lu=c3=ads_Henriques?= , Ilya Dryomov , Ceph Development , linux-kernel@vger.kernel.org References: <20211020143708.14728-1-lhenriques@suse.de> <34e379f9dec1cbdf09fffd8207f6ef7f4e1a6841.camel@kernel.org> <99209198dd9d8634245f153a90e4091851635a16.camel@kernel.org> From: Xiubo Li Message-ID: <785d1435-4a2c-95aa-0573-2de54b4e7b6b@redhat.com> Date: Tue, 26 Oct 2021 11:05:58 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/22/21 1:30 AM, Patrick Donnelly wrote: > On Thu, Oct 21, 2021 at 12:35 PM Jeff Layton wrote: >> On Thu, 2021-10-21 at 12:18 -0400, Patrick Donnelly wrote: >>> On Thu, Oct 21, 2021 at 11:44 AM Jeff Layton wrote: >>>> On Thu, 2021-10-21 at 09:52 -0400, Patrick Donnelly wrote: >>>>> On Wed, Oct 20, 2021 at 12:27 PM Jeff Layton 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 >>>>>>> Signed-off-by: Luís Henriques >>>>>>> --- >>>>>>> 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. >>> Maybe I'm confused. Is there some "file" which is already used for >>> this type of debugging information? Or do you mean the code for >>> sending stats to the MDS to support cephfs-top? >>> >>>> What's the specific problem with relying on the data in debugfs >>>> "metrics" file? >>> Maybe no problem? I wasn't aware of a "metrics" file. >>> >> Yes. For instance: >> >> # cat /sys/kernel/debug/ceph/*/metrics >> item total >> ------------------------------------------ >> opened files / total inodes 0 / 4 >> pinned i_caps / total inodes 5 / 4 >> opened inodes / total inodes 0 / 4 >> >> item total avg_lat(us) min_lat(us) max_lat(us) stdev(us) >> ----------------------------------------------------------------------------------- >> read 0 0 0 0 0 >> write 5 914013 824797 1092343 103476 >> metadata 79 12856 1572 114572 13262 >> >> item total avg_sz(bytes) min_sz(bytes) max_sz(bytes) total_sz(bytes) >> ---------------------------------------------------------------------------------------- >> read 0 0 0 0 0 >> write 5 4194304 4194304 4194304 20971520 >> >> item total miss hit >> ------------------------------------------------- >> d_lease 11 0 29 >> caps 5 68 10702 >> >> >> I'm proposing that Luis add new lines for "copy" to go along with the >> "read" and "write" ones. The "total" counter should give you a count of >> the number of operations. > Okay that makes more sense! > > Side note: I am a bit horrified by how computer-unfriendly that > table-formatted data is. Any suggestion to improve this ? How about just make the "metric" file writable like a switch ? And as default it will show the data as above and if tools want the computer-friendly format, just write none-zero to it, then show raw data just like: # cat /sys/kernel/debug/ceph/*/metrics opened_files:0 pinned_i_caps:5 opened_inodes:0 total_inodes:4 read_latency:0,0,0,0,0 write_latency:5,914013,824797,1092343,103476 metadata_latency:79,12856,1572,114572,13262 read_size:0,0,0,0,0 write_size:5,4194304,4194304,4194304,20971520 d_lease:11,0,29 caps:5,68,10702