From owner-freebsd-fs Sat Sep 13 15:01:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA02397 for fs-outgoing; Sat, 13 Sep 1997 15:01:54 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA02391; Sat, 13 Sep 1997 15:01:50 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id PAA29443; Sat, 13 Sep 1997 15:01:50 -0700 (MST) From: Terry Lambert Message-Id: <199709132201.PAA29443@usr03.primenet.com> Subject: Re: getcwd() as syscall... To: phk@FreeBSD.ORG (Poul-Henning Kamp) Date: Sat, 13 Sep 1997 22:01:50 +0000 (GMT) Cc: fs@FreeBSD.ORG In-Reply-To: <5464.874183620@critter.freebsd.dk> from "Poul-Henning Kamp" at Sep 13, 97 10:47:00 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-fs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Now that we have v_dd and v_ddid in the vnodes, and since the namecache > is quite reluctant to throw out directories, it would be possible to > make a "getcwdifyoucan()" syscall, which would run a lot faster than > the getcwd() library routine. > > The "ifyoucan" bit reflects that it may actually not be able to if the > required information isn't in the namecache, in which case I would > prefer to have userland fall back to the usual method, rather than > have to implement it in the kernel. > > I have no idea how much this would or wouldn't save in time. I know > that during a "make world", 13 % of the name cache lookups are for > "..", and quite a number of these probably come from getcwd(), so > there is something to go aim for. > > Comments ? I'd say try the cache first, and then do the work in the kernel to make it work. The work is going to be done on the users dime (quantum) anyway. Knowing the parent will save looking up "..". Otherwise, it won't be used much because it won't work on anything but UFS. There may be a problem with this, however, given that the parent may not know about the child. If the child has been deleted while it was someone's current directory, then the parent value needs to be set to 0 (or whatever other marker value) so that people with it open can distinguish an orphaned open directory from an unorphaned one. You can't use the link count because multiple people might have it open, and you won't be able to distinguish that from "I have it open and the other links are '.' and the one in the parent". Note: you need different markers for "deleted" and "root of FS"; I think "root of FS" should have itself (2) as the parent. Other than that, it's a *great* idea, and the purpose behind the parent pointers in the first place. 8-) 8-). Oh... is there an option to fsck to set these on a legacy FS? And has newfs been fixed to fill the values in for the default director{y/ies}? I know the code has a "create lost+found" option, even if it is never exercised... Finally, I'd be *real* tempted to make it an fcntl() instead of a system call, and make "-1" mean "cwd", so it can be used on fd's pointing to directories (saves on the system call name space, too). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.