From nobody Sun May 29 00:10:36 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1290E1B472F4 for ; Sun, 29 May 2022 00:10:45 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from tor1-11.mx.scaleengine.net (tor1-11.mx.scaleengine.net [209.51.186.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4L9f842jvCz3jJ9 for ; Sun, 29 May 2022 00:10:44 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.3] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by tor1-11.mx.scaleengine.net (Postfix) with ESMTPSA id 137577ACD for ; Sun, 29 May 2022 00:10:38 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 tor1-11.mx.scaleengine.net 137577ACD Message-ID: Date: Sat, 28 May 2022 20:10:36 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: fcntl F_KINFO for Content-Language: en-US To: freebsd-hackers@freebsd.org References: <5e7863b6-4c57-16a2-0b54-655defefb347@gmail.com> From: Allan Jude In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4L9f842jvCz3jJ9 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 209.51.186.6 is neither permitted nor denied by domain of allanjude@freebsd.org) smtp.mailfrom=allanjude@freebsd.org X-Spamd-Result: default: False [-0.03 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[allanjude]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(0.07)[0.066]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_SHORT(1.00)[1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:209.51.160.0/19, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 5/14/2022 3:53 PM, Konstantin Belousov wrote: > > When open(2) creates a new file, the vnode name is not entered into > the name cache. I believe this is done to smoother the case like > untarring large set of files, which would replace existing cached > entries with probably not too useful new entries. > > F_KINFO uses name cache to reconstruct the last element of the path, > on most real file systems like UFS. If this last element is not cached, > F_KINFO is unable to return the path. > Now that caches are bigger, might it make sense to have open() w/ O_CREAT create these namecache entries? Maybe we could purposely insert them in the middle of the list or something to avoid them pushing out other new entries or something. Specifically, having a more reliable way to get the path from an FD would be very useful, and maybe we need to reconsider some of the classic tradeoffs. -- Allan Jude