Re: [nfsv4] slides
"Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de> Sat, 16 May 2020 21:05 UTC
Return-Path: <tigran.mkrtchyan@desy.de>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F773A0914 for <nfsv4@ietfa.amsl.com>; Sat, 16 May 2020 14:05:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.426
X-Spam-Level: *
X-Spam-Status: No, score=1.426 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HK_RANDOM_ENVFROM=0.626, HK_RANDOM_FROM=0.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=desy.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2mkvUnBJjGh for <nfsv4@ietfa.amsl.com>; Sat, 16 May 2020 14:05:54 -0700 (PDT)
Received: from smtp-o-2.desy.de (smtp-o-2.desy.de [IPv6:2001:638:700:1038::1:9b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 212163A090F for <nfsv4@ietf.org>; Sat, 16 May 2020 14:05:53 -0700 (PDT)
Received: from smtp-buf-2.desy.de (smtp-buf-2.desy.de [IPv6:2001:638:700:1038::1:a5]) by smtp-o-2.desy.de (Postfix) with ESMTP id A072E160E3A for <nfsv4@ietf.org>; Sat, 16 May 2020 23:05:49 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp-o-2.desy.de A072E160E3A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=desy.de; s=default; t=1589663149; bh=WUyzQFtHVepTu8a+uqCs8AbBiMKbkgv/4n9xGHtzzSw=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=k+q1txFob9bRzEdXcxwrBnIMRm5UFnk624Pxbylm0EJI90z57vAYYt/P+4wy6Tffb BhMy9nC6THjCtpmkorduIrp9yHkx7bd2fa5pcHf7gnN8aLFltz2HUqiOaWJXLQF1fX m9ULInm9ytfgeroNx4lfGqj7yb7dNzVmMxfojrFU=
Received: from smtp-m-2.desy.de (smtp-m-2.desy.de [131.169.56.130]) by smtp-buf-2.desy.de (Postfix) with ESMTP id 95B231A00E2; Sat, 16 May 2020 23:05:49 +0200 (CEST)
X-Virus-Scanned: amavisd-new at desy.de
Received: from z-mbx-2.desy.de (z-mbx-2.desy.de [131.169.55.140]) by smtp-intra-3.desy.de (Postfix) with ESMTP id 6EA8280005; Sat, 16 May 2020 23:05:49 +0200 (CEST)
Date: Sat, 16 May 2020 23:05:49 +0200
From: "Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de>
To: Dave Noveck <davenoveck@gmail.com>
Cc: NFSv4 <nfsv4@ietf.org>
Message-ID: <120533000.6309384.1589663149366.JavaMail.zimbra@desy.de>
In-Reply-To: <CADaq8jf5vtshML+sEAQFx3gww7RKUBZAHpDzVGpVO8JUPHQVww@mail.gmail.com>
References: <CADaq8jf5vtshML+sEAQFx3gww7RKUBZAHpDzVGpVO8JUPHQVww@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_dc6b07f4-cf27-4136-8b1c-b32a7738bb71"
X-Mailer: Zimbra 8.8.15_GA_3901 (ZimbraWebClient - FF76 (Linux)/8.8.15_GA_3895)
Thread-Topic: slides
Thread-Index: jHfwGfJXJJqK81Xa8JQAde+JdLHu5Q==
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/V6Q6k2kcQxgEjsjYXhG8Kr5UDhQ>
Subject: Re: [nfsv4] slides
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 May 2020 21:05:56 -0000
Hi Dave,
Unfortunately I was unable to connect on April 29 ...
I have a comment about directory delegation.
For us (the crazy scientist) the directory delegation
*had* a big potential. First of all, some of our workflows
produce literally millions of files in a single directory,
something like generating a HD movie with one file per frame.
Second, as every scientist wants to be the first to make
the new discovery, people ran scripts that do `ls` in a loop
and spawn a processing job as soon as new a data is detected.
This makes GETATTR and REDDIR to most demanded operations.
To keep our users happy, we put a significant effort to make
directory listing as fast/cheap as possible and have introduced
so called 'storage events' - a mechanism where storage system can
perform user defined actions triggered on certain events. The AWS
Lambda is probably the closest commercial alternative.
There are two reasons why we didn't go for directory delegation:
- my poor skills as kernel developer
- the time it takes upstream kernel to
land on our production nodes (we still run RHEL6)
If interest is still there, I am not the one who can do the kernel work,
but I am ready to help with testing and provide a server implementation.
Indeed, the question is should NFS go in that direction. We have tamed
our local users, but there are many others around. Do they have similar
use-case? Do we know and understand their needs?
Best Regards,
Tigran.
----- Original Message -----
> From: "Dave Noveck" <davenoveck@gmail.com>
> To: "NFSv4" <nfsv4@ietf.org>
> Sent: Wednesday, April 29, 2020 6:59:44 PM
> Subject: [nfsv4] slides
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
- [nfsv4] slides David Noveck
- Re: [nfsv4] slides Mkrtchyan, Tigran