From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Subject: Re: [9fans] 9P2000 and p9p From: "Russ Cox" Date: Tue, 10 Apr 2007 14:29:32 -0400 In-Reply-To: <461BC57B.3090006@tecmav.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-Id: <20070410182940.6EC861E8C3B@holo.morphisms.net> Topicbox-Message-UUID: 4333a036-ead2-11e9-9d60-3106f5b1d025 > Why the client always sends a second Tread request ? > If the Rread returned 281/8192 bytes and the msize is > 8192 it should > be clear that there is no other data to read. As Charles pointed out, what you describe is in fact the behavior of fread(3) (from stdio) but is not the behavior of the underlying read(2) system call, even on Unix. An EOD flag can't work without either (a) changing the system call interface or (b) having some kind of lease so that the EOD can be invalidated when more data comes in between the first read and the second read (which you propose the operating system should answer without reference to the 9P server). The extra fids you see when mounting under Linux don't grow without bound. They are being stored in the Linux vnode cache, and if you build up enough of them eventually you will start seeing clunks even before unmounting the file system. I am sure Eric or Ron will chime in with some incantation to disable this caching in some way. Plan 9 does not cache directory tree information, so you don't see these extra fids on Plan 9. Russ