Re: Finding Blocks occupied by the file on the volume
Re: Finding Blocks occupied by the file on the volume
- Subject: Re: Finding Blocks occupied by the file on the volume
- From: Terry Lambert <email@hidden>
- Date: Thu, 21 Jul 2005 15:48:40 -0700
On Jul 21, 2005, at 7:03 AM, Shawn Erickson wrote:
On Jul 21, 2005, at 3:23 AM, santosh katvate wrote:
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
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.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden