The mode printed under the -l option contains 11 characters,
interpreted as follows: the first character is
d if the entry is a directory;
a if the entry is an append-only file;
- if the entry is a plain file.
Therefore, handle them in automatically generated directory listings.
David du Colombier wrote:
> The slowness issue only appears on the loopback, because
> it provides a 16384 MTU.
>
> There is an old bug in the Plan 9 TCP stack, were the TCP
> MSS doesn't take account the MTU for incoming connections.
>
> I originally fixed this issue in January 2015 for the Plan 9
> port on Google Compute Engine. On GCE, there is an unusual
> 1460 MTU.
>
> The Plan 9 TCP stack defines a default 1460 MSS corresponding
> to a 1500 MTU. Then, the MSS is fixed according to the MTU
> for outgoing connections, but not incoming connections.
>
> On GCE, this issue leads to IP fragmentation, but GCE didn't
> handle IP fragmentation properly, so the connections
> were dropped.
>
> On the loopback medium, I suppose this is the opposite issue.
> Since the TCP stack didn't fix the MSS in the incoming
> connection, the programs sent multiple small 1500 bytes
> IP packets instead of large 16384 IP packets, but I don't
> know why it leads to such a slowdown.
apache sends Content-Encoding: gzip header for Content-Type: application/x-gzip
causing hget to decompress tgz files.
from the w3c:
The Content-Encoding entity-header field is used as a modifier to the media-type.
When presented, its value indicates what additional content codings have been applied
to the entity-body, and thus what decoding mechanisms must be applied in order to
obtail the media-type referenced by the Conent-Type header field. Content-Encoding
is primarily used to allow a document to be compressed without losing the
identity of its underlying media type.
this is clearly silly, as the file is already compressed, and decompressing it
will not yield the indicated Content-type: application/x-gzip, but a tarball.
examples:
http://zlib.net/zlib-1.2.8.tar.gzhttps://www.mirbsd.org/MirOS/dist/mir/mksh/mksh-R50f.tgz
i made a mistake here as this change breaks the arm and mips compilers
which lack an optimiation in xcom() that folds constant pointer arithmetic
into the offset. on arm, the a node is a complex expression with op OADD of
type TIND but the test rejected the (valid) pointer arithmetic.
instead, we now test for the operations which cannot be constant instead
of using the type as a proxy.
mischief spotted that the only way for listeners to go away was
truncating (but not removing) a service script. this is wrong and
not as described in the manpage.
this change makes removing (or truncating) a listen script stop
the listener.
scandir() first marks all current announces, then reads the service
directory adding announces which will clear the marks for the ones
already there or add a new unmarked one. finally, we shoot down and
remove all still marked announces.
6c changed "- cmd_lagest_size + 1" into a *unsigned* 32bit constant. which
got added to 64bit pointer making pcb->limit > pcb->end resulting
in errors for partial commands in the buffer. removing the parentesis
propagates the operation to 64bit.
the intend of posting a note to the faulting process is to
interrupt the syscall to give the note handler a chance
to handle it. kernel processes however, have no note handlers
and all the postnote() does is set up->notepending which will
make the next attempt to sleep raise an Eintr[] error. this
is harmless, but usually not what we want.
there's no need to waste space for a error buffer in the Segio
structure, as the segmentio kproc will be waiting for the next
command after an error and will not overwite it until we issue
another command.
devproc's procctlmemio() did not handle physical segment
types correctly, as it assumed it can just kmap() the page
in question and write to it. physical segments however
need to be mapped uncached but kmap() will always map
cached as it assumes normal memory. on some machines with
aliasing memory with different cache attributes
leads to undefined behaviour!
we borrow the code from devsegment and provide a generic
segio() function to read and write user segments which
handles all the cases without using kmap by just spawning
a kproc that attaches the segment that needs to be read
from or written to. fault() will setup the right mmu
attributes for us. it will also properly flush pages for
segments that maintain instruction cache when written.
however, tlb's have to be flushed separately.
segio() is used for devsegment and devproc now, which
also allows for simplification of fixfault() as there is no
special error handling case anymore as fixfault() is now
called from faulting process *only*.
reads from /proc/$pid/mem can now span multiple pages.
code like "return g->dlen;" is wrong as we do not hold the
qlock of the global segment. another process could come in
and override g->dlen making us return the wrong byte count.
avoid copying when we already got a kernel address (kernel memory
is the same on processes) which is the case with bread()/bwrite().
this is the same optimization that devsd does.
also avoid allocating/freeing and copying while holding the qlock.
when we copy to/from user memory, we might fault preventing
others from accessing the segment while fault handling is in
progress.
