From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4311DC32771 for ; Mon, 20 Jan 2020 20:52:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 06FD122522 for ; Mon, 20 Jan 2020 20:52:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Wz8jTlNE" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727665AbgATUwl (ORCPT ); Mon, 20 Jan 2020 15:52:41 -0500 Received: from mail-pg1-f172.google.com ([209.85.215.172]:45931 "EHLO mail-pg1-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728587AbgATUwl (ORCPT ); Mon, 20 Jan 2020 15:52:41 -0500 Received: by mail-pg1-f172.google.com with SMTP id b9so234841pgk.12 for ; Mon, 20 Jan 2020 12:52:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:subject:to:cc:in-reply-to:references:organization :mime-version:date:user-agent:content-transfer-encoding; bh=oT/PEKHTDAEu4Wui9vP14UawSG7Ju8CU4hlVQn4lc1o=; b=Wz8jTlNEafex2bJJrdN/eZ+AajqrUlo6ohnviz7TX8kqn7QFZiija4Nbu1gBIkApy8 GHvTHsKWJVbWRQhNHLYsg3e4ic7HOtnYY2MXyy1WKL2wNV4oWwhKjKTd8NO2qY1NgnTC sDMAtByusflI3kkNRoRGTv3TTOfyPcep2SUKBQq+PcCJy9/6ME6qMlPjkrgtdFX4tgxp xWmCs0JmOF2T05EzVonhR4D57OV4dHNCaJw52ShUbZ7u2XNVIyyzeotYOqZ06sROz3rQ f59pxJ7uO1YeFFsLK8idEV9KsldHwfKSEZTPnj1aVvvOaKkXGnPnxFhBZnDSA78bbzab mu4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:subject:to:cc:in-reply-to :references:organization:mime-version:date:user-agent :content-transfer-encoding; bh=oT/PEKHTDAEu4Wui9vP14UawSG7Ju8CU4hlVQn4lc1o=; b=WJwLE/beylwXTnUgz5H4CT1wEh2p0xEID+UEtxD4uJDuKmTfeGKilSv2z4LLEX9bYK d1knTiL2WQsyv/MXNX80omASJt/vabYQKl6p0DOJuIcXKXszqz6c7qJUhfcvuHEkeaJd 5RCstChhjw9WhrycaVeR9a0U387Y2guEavGfQx4Cx6guZFzlbq3wFiE09t57w59YEFJk oDCNE7MTf2nUfzK2QL25kL2Fq9YQ0CvTBBJsy489O9Qm5kfDqPNeDO8D8MFMbjWkhYmm Xocvm0TlNDLyuyY/XsDlEJO4RjVNN3jnoHVaPUNhqBHoRBTozb8RbX5WV8Hf9GV+D7e9 EGrA== X-Gm-Message-State: APjAAAVGoUTUWfzoL632bwZxvnK6n0dWvy62Vo4UVOJ9aSAKF9TA/jhh Yyg+QESBOK6ce370+sSt4A== X-Google-Smtp-Source: APXvYqy2npV2Lzsdw8p4hhzNp+FbCrfOzHS6d8ttkHvZNaV+I/t+dhP9ONzQoX2bTnb8zlnZxtMgnQ== X-Received: by 2002:a63:8c48:: with SMTP id q8mr1623390pgn.213.1579553560383; Mon, 20 Jan 2020 12:52:40 -0800 (PST) Received: from leira (63-235-104-78.dia.static.qwest.net. [63.235.104.78]) by smtp.gmail.com with ESMTPSA id c17sm39575851pfi.104.2020.01.20.12.52.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Jan 2020 12:52:39 -0800 (PST) From: Trond Myklebust X-Google-Original-From: Trond Myklebust Message-ID: <388ff8a1abebdf0eab8e696cb09148c0704dd766.camel@hammerspace.com> Subject: Re: 'ls -lrt' performance issue on large dir while dir is being modified To: Dai Ngo , "chuck.lever@oracle.com" Cc: "linux-nfs@vger.kernel.org" , "Anna.Schumaker@netapp.com" In-Reply-To: <52079beb-1f27-35d8-c92a-6a6b430c7c8f@oracle.com> References: <770937d3-9439-db4a-1f6e-59a59f2c08b9@oracle.com> <9fdf37ffe4b3f7016a60e3a61c2087a825348b28.camel@hammerspace.com> <49bfa6104b6a65311594efd47592b5c2b25d905a.camel@hammerspace.com> <8439e738-6c90-29d9-efc8-300420b096b1@oracle.com> <43fae563e93052f9dc9584ddd800770a7b3b10d2.camel@hammerspace.com> <9327BCC2-6B75-47E3-8056-30499E090E18@oracle.com> <3456dea05ac1a2d82c077146e8638130e313edca.camel@hammerspace.com> <52079beb-1f27-35d8-c92a-6a6b430c7c8f@oracle.com> Organization: Hammerspace Inc Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Mon, 20 Jan 2020 12:52:13 -0800 User-Agent: Evolution 3.34.3 (3.34.3-1.fc31) Content-Transfer-Encoding: 7bit Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Sat, 2020-01-18 at 10:03 -0800, Dai Ngo wrote: > > I think this is the contention point: the spec did not explicitly > mention anything regarding mixing of cookies from READDIR & > READDIRPLUS. > > However, as I mentioned, the current client implementation already > mixing > cookies between READDIRPLUS and READDIR, everytime the user does a > simple > 'ls' on a large directory, without invalidating any mapping. > > Also, as Chuck mentioned, we're not aware of any server > implementation > that has problems with this mixing of cookies. > OK I did a little time warp and went back to the original emails around this behaviour: https://linux-nfs.vger.kernel.narkive.com/O0Xhnqxe/readdir-vs-getattr Part of the problem that needed solving at the time was that even when the directory and its contents were not changing, people were still needing to do reams of GETATTR calls in order to typically satisfy an 'ls -l' or even 'ls --color'. When we see that pattern, we want to switch from using GETATTR on all these files to using READDIRPLUS. The cache invalidation was introduced in order to force the NFS client to do these READDIRPLUS calls so we avoid the GETATTRs. So one optimisation we could definitely do is try to track the index of the last page our descriptor accessed on readdir(), and truncate only the remaining pages. That way we don't keep re-reading the beginning of the directory. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@hammerspace.com