Date: Tue, 31 Oct 2000 14:25:53 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dufault@hda.com (Peter Dufault) Cc: dillon@earth.backplane.com (Matt Dillon), tlambert@primenet.com (Terry Lambert), ryan@sasknow.com (Ryan Thompson), freebsd-hackers@FreeBSD.ORG Subject: Re: Filesystem holes Message-ID: <200010311427.HAA27852@usr06.primenet.com> In-Reply-To: <200010311235.HAA31834@hda.hda.com> from "Peter Dufault" at Oct 31, 2000 07:34:16 AM
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. SVR4 defined F_FREESP; if passed to fcntl, it will call the VOP_SPACE routine. The third argument is a struct flock, and it used to be that it only supported l_len == 0, but that changed in 1993/1994, about the same time we got sfork support flogged into it past the USL Process (caps intentional). 1993 was too late to get either interface fully documented in "The Magic Garden Explained", unfortunately, but it's been in SVR4 (along with sfork, via an ioctl against /proc), since back then. POSIX was unwilling to take a stand on the F_FREESP vs. ftruncate war, and so they remained agnostic, and didn't document anything. FWIW, the SVR4 interface is better, since it allows you to open holes. It was surprisingly hard to get simple changes like this past the keepers of the keys to the USL source tree. After we found out why, it became more understandable: the USL source code is built like a trinary nerve gas weapon, and you have to touch all three parts to get a change into the code. It's really rather arranged So That Things Will Not Change. My preference would be to hook it into fcntl, with F_FREESP, with the extended interface that can do more than truncate. This would require adding a "VOP_SPACE" type thing. There was also an undocumented F_ALLOCSP; I don't remember if that got folded in with the rest of the code, or if it got left out, but it does the obvious thing: allocated backing pages. 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: int i = 1; fcntl( fd, F_NONPOSIX, &i); It would help out the NFS locking daemon to no end... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?200010311427.HAA27852>