Date: Mon, 27 Oct 1997 21:57:50 -0500 (EST) From: Alfred Perlstein <perlsta@cs.sunyit.edu> To: Mike Smith <mike@smith.net.au> Cc: hackers@freebsd.org Subject: Re: help with fstat? Message-ID: <Pine.BSF.3.96.971027215728.1224B-100000@server.local.sunyit.edu> In-Reply-To: <199710280114.LAA00495@word.smith.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
thank you, i just wasn't sure of a way to go at this, but now mmap seems awesome. On Tue, 28 Oct 1997, Mike Smith wrote: > > 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?Pine.BSF.3.96.971027215728.1224B-100000>