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:
and provides (IMHO) about 98% of the needed, everyday functionality -- in fact,
if you don't need the _really_ exotic commands, it's faster (=better?) and uses
*much* less memory (especially when you have many users logged in at once) than
-the majority of the FTP servers out there... (6 line sentence.)
+the majority of the FTP servers out there... (5 line sentence.)
This program is GPLed, version 2 (see the file COPYING), not any later or
earlier version (later versions will probably `upgrade' to new GPLs as they
projects / betaftpd / blobdiff