Date: Tue, 31 Oct 2000 09:57:28 -0500 (EST) From: Peter Dufault <dufault@hda.com> To: Terry Lambert <tlambert@primenet.com> Cc: Peter Dufault <dufault@hda.com>, Matt Dillon <dillon@earth.backplane.com>, Ryan Thompson <ryan@sasknow.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: Filesystem holes Message-ID: <200010311458.JAA32216@hda.hda.com> In-Reply-To: <200010311427.HAA27852@usr06.primenet.com> from Terry Lambert at "Oct 31, 2000 02:25:53 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > I use them for bus simulations, which also are permanently sparse. > > It would be nice to free up the regions when I "remove" a virtual > > board, but in a check through POSIX I could find nothing defined to > > behave that way either for mapped files or mapped memory objects. > (...) > > POSIX was unwilling to take a stand on the F_FREESP vs. ftruncate > war, and so they remained agnostic, and didn't document anything. No, IIRC POSIX defines ftruncate behavior both for mapped files and shared memory objects but that isn't much use for freeing up holes unless you want to repopulate chunks after the hole. All in all I agree with Matt about the suitability of large sparse files for data storage. My case is different in that I want to test object code in pretty much its final form and legacy code will be full of brute force address calculations. ... > Peter: for your rewriting problem, I think you could just decide > to hold a write lock on the range you didn't want rewritten; so > long as it honors the advisory locks, there'd be no chance of it > screwing up, unless you got bit by the stupid POSIX lock close > semantics. Stupid POSIX; that's the other one I'd put in: the > ability to: I never thought of that. I'll look at it. I'll have to see how it is defined in POSIX and how it plays with shared memory objects on Solaris - currently I have no differences in the code other than defining shmopen to be (errno = ENOSYS, -1) if shared memory objects aren't supported and I fall back to mapped files and it all works well. One unfortunateness, though, is that Solaris requires that shared memory objects have the name of a file in "/" where I typically don't want to place multi gigabyte files even when they are allegedly sparse, requiring placing shared memory objects and shared files in different places and also having names such as "/vme_pid7662_data64" since I can't have subdirs. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200010311458.JAA32216>