site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com hi mike If i keep the handle of the file open then i don't think that filesystem will try to recycle the blocks corresponding to file as long as the handle is open -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... On Jul 21, 2005, at 7:03 AM, Shawn Erickson wrote: On Jul 21, 2005, at 3:23 AM, santosh katvate wrote: This is a very unsafe assumption. For example in that same document you are looking at review the section on "Hot Files" [1]. If the volume is mounted then the HFS+ file system code owns that file system, it can do whatever it wants with blocks of data on disk totally independent of what system level calls are made. You really cannot make any safe assumptions about how blocks will exist on disk as long as a file system driver owns the volume and you don't really have a good API that will let you get at that information from the file system driver itself, that I know of at least. -Shawn I understand the persistence of the question; Windows supports an IFS API mechanism for getting this information. For it to work there, you basically have to assert a level 3 volume lock, and a level 0 volume lock, lock the file, and get the information using a (sparsely documented) FS_Ioctl16Drive via INT 21 API. The primary reason people use this interface on Windows is, as Quinn suspected such an interface might be used, to do direct I/O to the disk, bypassing the IFS. In the general case, it's only ever done by Windows itself, in order to support swap files for use by the OS. By avoiding the IFS layer, they avoid the physical to logical device translation, and the logical device to IFS layout translation, which is expensive, partly because the way the API is laid out, and partly because of the disk structure. The API was originally invented because doing random I/O to FAT FSs in all their variants required traversing the FAT chain from the start to whatever offset where you wanted to do the I/O at. By asking for the block map up front, they converted this from an O(N!) operation for simple sequential I/O requiring disk I/O to an O(?) operation in memory (even if ? := N!, it's faster). This works because the IFS makes a contract with the IFSMgr to guarantee that a locked file will not have its blocks relocated on the disk. IFSMgr, at least in the past, punted in this area by not supporting swapping on removable media (I found this out in 1996, while working at another company, when I tried to install Windows 95 on a JAZ disk, and had strange error). In MacOS X, there is no such contract on open or locked files (just as Shawn says, here). In fact, there are FS's, specifically, some FS's backed by flash devices are designed to evenly distribute write cycles over the flash device to increase lifetime, given a finite number of write cycles per cell, where this is *not* true and *cannot* EVER be true and still achieve the FS design goals. In other words, whatever you do with an interface like this, it will probably break in the future as FS technology continues to evolve past your assumptions, if not immediately from some third party VFS. Supporting this yourself will mean taking the file system (or fsck) source code, and looking at how the physical disk is laid out, assuming you can get at the disk in the first place (i.e. it's not mounted so the raw device can be opened). Even then, we don't promise to not change things out from under you, and third party VFS's *certainly* make no such promise. You might be better off supplying your own VFS based on the FS you are trying to do this for, and adding your own entry-point hooks to additional functions via VNOP_IOCTL to do the work of locking/ unlocking/getting block information under the covers. I'd like to *strongly* discourage you from going this route; if you are going to go anywhere near it, you might as well make your VNOP_IOCTL do the work right then, instead of externalizing it via a new API that you will have to update each time a Software Update happens to bump the minor version number. This email sent to site_archiver@lists.apple.com