Date: Tue, 28 Oct 1997 11:44:19 +1030 From: Mike Smith <mike@smith.net.au> To: Alfred Perlstein <perlsta@cs.sunyit.edu> Cc: hackers@freebsd.org Subject: Re: help with fstat? Message-ID: <199710280114.LAA00495@word.smith.net.au> In-Reply-To: Your message of "Sun, 26 Oct 1997 21:31:01 CDT." <Pine.BSF.3.96.971026212719.19711B-100000@server.local.sunyit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> don't want to look a gift answer in the mouth but i don't think this is a > good idea, i'm working on a distributed system for transfering files > across the internet. the system is supposed to be able to manage a large > load of file transfers over TCP. On the contrary, it's an *excellent* idea. > if i mmap tons of files across many processes i think i will cause a large > amount of unnessesary paging, as most of the files will be in the > 200k-5meg range this will be too much laod on the system. > > unless mmap() maps in on demand... but i think i'll be eating up all my > address space... mmap() just associates a region of your address space with the file; until you actually reference it, you won't get any paging activity. As for eating up your address space, if you're only dealing with little files like you describe you won't have any trouble at all. I'm regularly mapping files in the 100M range, and it beats the hell outa reading them in record by record. > isn't fstat supposed to be what i'm looking for? No. > i don't want to exhaust the virtual memory on the machine, just get > optimal transfers. You won't exhaust virtual memory; mmapped regions are backed by the file, not by swap. mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710280114.LAA00495>