From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-f46.google.com (mail-io1-f46.google.com [209.85.166.46]) by sourceware.org (Postfix) with ESMTPS id 4613938582A6 for ; Sun, 24 Dec 2023 00:47:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4613938582A6 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=nrubsig.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 4613938582A6 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=209.85.166.46 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703378860; cv=none; b=OlOUMrZmEQMMPttXyyS0vgrnXXs6evAn2MCRqGuacM2PfVKudbZS6ovDuTTwdbwCX0Mq4aQAS84AaA5CRM/4CaILA12W8z9o8Lyl0YY3qo0Xh6QXmrGQZY9Bix1VZMdxBUrm3ilpRuWza8v+Li7eXKtJMUeL14lJsZobdKaEvxI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703378860; c=relaxed/simple; bh=qx4p5c78CRjJgqrG6R3mEoh+gEXYd/KzYnYi8yu6BLc=; h=MIME-Version:From:Date:Message-ID:Subject:To; b=FCpNfkCAs8MCnHU18l0nHjXUJrzZFpgjwIPtOgKtcLeitgZhaBPE2070pRDvJeBks4NDlv+IqHYWDMIgwfb2QFU7UxRHnLGW7a1XUlqrr81t2Ka+xojFmzd+LAH30RkyNNWbbqMriPd6x2ecVef8nlKDyAEgSnsNhkB1GFW1EcI= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-io1-f46.google.com with SMTP id ca18e2360f4ac-7b7a9f90f34so157141339f.2 for ; Sat, 23 Dec 2023 16:47:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703378855; x=1703983655; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=8GnMwlKpfhY5JvaBhxxnUk2nFC/47olH2b/1enJpJs4=; b=gz7qTJooMFLGeOr9QjZSZOoXezyV6aqWpzBAnvR1gJtFzhVanMQagK5ZYQg8uJMMhA IIIP9KtW4VGjC+sjQ5Bck2syLnei+vUtFfAocq6sL6wPAVeCFefLXhRl3gHc8cNc5JCr byTSOjowSXflivSUtZ2edG+aoquq1ETAS9B5gzrwuCcyMhuzfhyUOzyhnFdIp3R0xMpM BJCyeEDHppUO18x5i/ed4nXJnXZ8Oh/PWHNlZSCOWSEk068iwrCOxe1WiDhftFRr2suA R5xsc5v0dzvlYGfNBVBbxUwYXa7wXTS9e3ECWwrBkUuMjRKKU4V2fDwI9ziH/g0etWmb G00g== X-Gm-Message-State: AOJu0YyryNLJtTZWpal6WZPd+WlxPLnfDRzo2UsAksgJnc++gvgwgSn8 whaCGVT0YuWN+Czvh40Sysv3eeAN6h7MLzyyEnyX9zBoxUI= X-Google-Smtp-Source: AGHT+IFtEjRkkuWayz3djnb44LHtq6vhqOyjkcDNagGoski/0Sg/awKI8PBE9ofHx21Sx5FwxWeVYxmhE1PdbDrdrKA= X-Received: by 2002:a92:ca0e:0:b0:35d:59a2:bd2 with SMTP id j14-20020a92ca0e000000b0035d59a20bd2mr3426887ils.104.1703378855416; Sat, 23 Dec 2023 16:47:35 -0800 (PST) MIME-Version: 1.0 References: <07c7379e983c9f436ebf86e3818ca843@kylheku.com> <4723aab7e2b331cb81946eff0fb4e862@kylheku.com> In-Reply-To: <4723aab7e2b331cb81946eff0fb4e862@kylheku.com> From: Roland Mainz Date: Sun, 24 Dec 2023 01:47:09 +0100 Message-ID: Subject: Re: rfe: CYGWIN fslinktypes option? Re: Catastrophic Cygwin find . -ls, grep performance on samba share compared to WSL&Linux To: cygwin@cygwin.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, Dec 21, 2023 at 9:32=E2=80=AFPM Kaz Kylheku via Cygwin wrote: > On 2023-12-21 04:16, Martin Wege via Cygwin wrote: > > On Wed, Dec 20, 2023 at 6:21=E2=80=AFPM Kaz Kylheku via Cygwin > > wrote: [snip] > > The root cause is IMO the extra Win32 syscalls (>=3D 3 per file lookup, > > compared to 1 on Linux) to lookup the *.lnk and *.exe.lnk files on > > filesystems which have native link support (NTFS, ReFS, SMBFS, NFS). > > On SMBFS and NFS it hurts the most, because access latency is the > > highest for networked filesystems. > > Could some intelligent caching be added there? (Discussion of > associated invalidation problem in 3... 2.... 1... ) See below, basically a short-lived cache which is only valid for the lifetime of the one POSIX function call would be OK... > Can you discuss more details, so people don't have to dive into code > to understand it? If we are accessing some file "foo", the application > or user may actually be referring to a "foo.lnk" link. But in the > happy case that "foo" exists, why would we bother looking for "foo.lnk"? > > If "foo" does not exist, but "foo.lnk" does, that could probably be > cached, so that next time "foo" is accessed, we go straight for "foo.lnk"= , > and keep using that while it exists. > > If someone has both "foo" and "foo.lnk" in the same directory, > that's a bit of a degenerate case; how important is it to be "correct", > anyway. Question, mainly for Corinna: Could the code be modified to use one |NtQueryDirectoryFile()| call with a SINGLE pattern testing for { "foo", "foo.lnk", "foo.lnk.exe", ... } (instead of calling the kernel for each suffix independently) and cache that information for the lifetime of the matching POSIX function call ? The idea is to reduce the number of userland<--->kernel roundstrips from to <1>, and filesystem drivers could be optimized even further (for example if the network filesystem protocol supports file name globbing...) ---- Bye, Roland --=20 __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /=3D=3D\ O\ TEL +49 641 3992797 (;O/ \/ \O;)