> > 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 ([EMAIL PROTECTED]) Realtime development, Machine control,
HD Associates, Inc. Fail-Safe systems, Agency approval
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
