process_all_clients(): Fixed a bug (reporting and much tracing by Sean MacLennan...

[betaftpd] / README

diff --git a/README b/README
index 760a1aa110023d795a9d21b772bc0905c239710d..9a39e318271f422d23f180030e228e5f4d6b7bd3 100644 (file)
--- a/README
+++ b/README
@@ -112,11 +112,20 @@ if you were serving the same 128MB file 10 times, top would claim you used over
 a gigabyte of memory, still only a couple of megabytes would be used at most,
 as cache. If you ran out of memory, this could actually shrink to zero. It's
 just that the kernel tries to be more effective (and it succeeds) by reducing
-the number of reads, and instead reading larger chunks at once.
-
-If sendfile() support is enabled, and the circumstances allow it (binary mode
-downloading), BetaFTPD will not mmap() at all, bringing the memory total down
-to a more realistic value.
+the number of reads, and instead reading larger chunks at once. Actually, for
+32-bit architectures, if you serve large several large files, you might get a
+problem with hitting the 2GB address space (every mmap() counts towards this
+limit, it appears). The solutions are many: Use sendfile() (see below), do
+without mmap, or enable high memory support in your kernel (at least Linux
+2.3/2.4 can do this at compile time). For most of us, though, this will never be
+a problem, just be aware of it if you're doing a benchmark, for instance. Future
+versions of BetaFTPD might just mmap() once per file (instead of once per
+transfer per file), but this is probably more problems than it's worth.
+
+If sendfile() support is enabled (note that only Linux sendfile() is working at
+the moment, BSD sendfile() is detected but not utilized), and the circumstances
+allow it (binary mode downloading), BetaFTPD will not mmap() at all, bringing
+the memory total down to a more realistic value.
 
 Bragging:
 
@@ -157,11 +166,14 @@ under). For more info on the GPL, visit http://www.gnu.org/ .
 
 7. Where to get new versions, contact me etc.
 ---------------------------------------------
-E-mail:                        sgunderson@bigfoot.com (all spam/flame go
-                       to antispam@bigfoot.com or /dev/null)
 Homepage, new versions:        http://betaftpd.sourceforge.net/
 Mirror site:           ftp://metalab.unc.edu/pub/Linux/system/network/daemons/
                        (Note that Metalab will always lag behind a few days, and
                         doesn't carry beta versions.)
 
-                       There are more mirror sites at the homepage.
+The homepage also contains information on how to get the very latest copy of
+BetaFTPD via CVS, a bug tracker, a patch tracker, more mirror pages, nightly
+CVS tarballs and much more, thanks to SourceForge. The old page at xoom.com
+has been discontinued; please update your links accordingly.
+
+-Steinar H. Gunderson <sgunderson@bigfoot.com>