From patchwork Sat Apr 23 23:48:16 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Noah Watkins X-Patchwork-Id: 8919261 Return-Path: X-Original-To: patchwork-ceph-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 87F69BF29F for ; Sat, 23 Apr 2016 23:48:25 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 91ABB201FA for ; Sat, 23 Apr 2016 23:48:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 444A720155 for ; Sat, 23 Apr 2016 23:48:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752225AbcDWXsS (ORCPT ); Sat, 23 Apr 2016 19:48:18 -0400 Received: from mail-ig0-f177.google.com ([209.85.213.177]:37797 "EHLO mail-ig0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751706AbcDWXsR (ORCPT ); Sat, 23 Apr 2016 19:48:17 -0400 Received: by mail-ig0-f177.google.com with SMTP id g8so46734282igr.0 for ; Sat, 23 Apr 2016 16:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=vhuQVPGorNcnWk/xrDKBy+ItC6mYCaIp4MBA6hCSpHQ=; b=QfXVu+lv2MbjOnrt6OZKu9aSBulaMY87XSBwKLhZFK3jxRVGDsDcPq3+yibMvvYVuF JTgQWhdAIG/gWFEgGYaG35OaBotPnEjGccKc175FUvSlDccaLVhj3kWDXjkRcTUjZfVy kKuHfH/fQWAtmeB86chUPkkxyknsBhXUTAAb3LvHYy1hNciXtg/tiMRlPpRzemaj1joR bNaJRIWyIhJ7qAI05tBfkFdmkeU6Yp1dPRrKEi0NjL7pzDX4+YaGlsfu1P+ZLu5fPcpx O2RfFJbVSwNlb17utr8wHFsFD8NeimXFKlqQKhSHIGy+iBUPYC0hpzSWeScAJHXZs+YE 9fhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=vhuQVPGorNcnWk/xrDKBy+ItC6mYCaIp4MBA6hCSpHQ=; b=EjZzcyCayMZcAUunhlh6zqKD2jQqvMp/cDn9kkcYHu31B3fokqe42cLtTWaoRgPpoB hCv81ETZTaCtbdAKrjTKPBD0wjyMEQBuxMdChdG/Q5X5ePqpMZqSbkyQaD7hlqRAJNQu 5K8GWiHouNZRsMdz1tM8MZtDdaDyYz3HbL5f3R1WQZeBjheQ1FV8fiVZlW5Fa5mYJ7EN sXpZp/CY9ltjNZCdyny6GQT52ha3Nm882w5Ws38ewCqG7wBnzK0bdeY4/Xy3zMHyEECl Ol0PgNDnMpvSk9zg3Wq9DcVtxIAqgCIE+QUIMggC4tUFpGFbskqgMrFHJtCl25eI7Xa4 qvfQ== X-Gm-Message-State: AOPr4FVPXDBEkXIUiOoPziVPHAWpruBQajMDYD0zPCPS91imTFBnR5yVYn3SlnR3C5NVf2woEgjIZsnjta/1kQ== MIME-Version: 1.0 X-Received: by 10.50.27.39 with SMTP id q7mr4793829igg.34.1461455296203; Sat, 23 Apr 2016 16:48:16 -0700 (PDT) Received: by 10.64.62.206 with HTTP; Sat, 23 Apr 2016 16:48:16 -0700 (PDT) In-Reply-To: References: Date: Sat, 23 Apr 2016 16:48:16 -0700 Message-ID: Subject: Re: cap mask differences for `Client::stat` vs `Client::fstat` From: Noah Watkins To: "Yan, Zheng" , Gregory Farnum Cc: ceph-devel Sender: ceph-devel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: ceph-devel@vger.kernel.org X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP I have a patch for this (below), but I see something that doesn't seem quite right. Here is a simple fs client. When its running by itself the fstat/sec rate is high. When a second client copy of this client starts, the first client slows down as expected, but the new client blocks. I would expect both clients to make progress, but until the first client exits, the second client is blocked. fd = cephfs.open('file-1', 'w', 0755) count = 0 start = time.time() while True: stat = cephfs.fstat(fd) count += 1 if time.time() > (start + 1): print(count) count = 0 start = time.time() - Noah Patch: 709840b - fsclient: fstat can take inode all cap (10 minutes ago) > On Thu, Apr 14, 2016 at 1:26 AM, Noah Watkins wrote: >> In the libcephfs client it looks like both `Client::stat` and >> `Client::lstat` use a default mask of CEPH_STAT_CAP_INODE_ALL and are >> able to return immediately from `Client::_getattr` without making an >> MDS request. However, `Client::fstat` uses hard-coded -1 as the cap >> mask and always issues a MDS request. Is this the intended behavior, >> and if so, what are different semantics of fstat that make this a >> requirement? > > I think it's a bug, Client::fstat should use CEPH_STAT_CAP_INODE_ALL too. > > Regards > Yan, Zheng > >> >> Thanks, >> Noah >> -- >> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html --- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/src/client/Client.cc b/src/client/Client.cc index 7fcd907..94e4db5 100644 --- a/src/client/Client.cc +++ b/src/client/Client.cc @@ -8668,16 +8668,16 @@ int Client::_fsync(Fh *f, bool syncdataonly) return _fsync(f->inode.get(), syncdataonly); } -int Client::fstat(int fd, struct stat *stbuf) +int Client::fstat(int fd, struct stat *stbuf, int mask) { Mutex::Locker lock(client_lock); - tout(cct) << "fstat" << std::endl; + tout(cct) << "fstat" << " mask " << mask << std::endl; tout(cct) << fd << std::endl; Fh *f = get_filehandle(fd); if (!f) return -EBADF; - int r = _getattr(f->inode, -1); + int r = _getattr(f->inode, mask); if (r < 0) return r; fill_stat(f->inode, stbuf, NULL); diff --git a/src/client/Client.h b/src/client/Client.h index d912db0..860f28b 100644 --- a/src/client/Client.h +++ b/src/client/Client.h @@ -981,7 +981,7 @@ public: int fake_write_size(int fd, loff_t size); int ftruncate(int fd, loff_t size); int fsync(int fd, bool syncdataonly); - int fstat(int fd, struct stat *stbuf); + int fstat(int fd, struct stat *stbuf, int mask=CEPH_STAT_CAP_INODE_ALL); int fallocate(int fd, int mode, loff_t offset, loff_t length); On Wed, Apr 13, 2016 at 6:49 PM, Yan, Zheng wrote: