site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com -- 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 Dec 11, 2007, at 12:46 AM, Anton Altaparmakov wrote: On 11 Dec 2007, at 00:00, Terry Lambert wrote: On Dec 8, 2007, at 1:51 AM, Anton Altaparmakov wrote: As there is no sparse support this is not relevant. You can get allocation information using the fcntl F_LOG2PHYS (see the fcntl man page) but that is quite a cumbersome interface. Also note that it will (at least on Leopard have not checked Tiger) return RANDOM JUNK for file systems supporting sparse files. Radar is down for maintenance at the moment or I would file a bug report immediately! Which FS are you talking about? For UFS, I see zero filled pages being returned, which is per the spec.. Are you sure this is not a bug specific to the FS you were testing on? The FS is more or less required to fake this up for any sparse areas, and if it doesn't, it's broken (not to mention a security issue, if it's returning random data from the disk). You misunderstood. Read the fcntl man page, the bit about F_LOG2PHYS. That returns a structure: struct log2phys { u_int32_t l2p_flags; /* unused so far */ off_t l2p_contigbytes; /* unused so far */ off_t l2p_devoffset; /* bytes into device */ }; And the l2p_devoffset contains random junk when F_LOG2PHYS is called for a sparse block. The bug is in the fcntl F_LOG2PHYS implementation in the kernel. If you want the gory details I described it in the Radar I filed: <rdar://problem/5637597>. Ah, OK. I consider that fcntl() to basically be SPI at this point. If you can make a business case as to why you need access to F_LOG2PHYS, we can maybe change this. We mostly didn't expect people to try to use that call, given that they are not allowed direct access to the device while it's mounted enough for you to be able to make the call to ask. The F_LOG2PHYS turns into a VNOP_BLOCKMAP, which the FS is supposed to handle. Mostly, this is used by hfsutil and the boot cache only, which makes it pretty special case code. In HFS, this turns out to be iterrable as an extent list (if the file is not a single extent). For UFS, you are correct:: you will not get valid information for sparse regions. I'm not sure this is really a bug. The documentation is pretty clear that "For some filesystems it might be too inefficient to provide anything beyond the advisory value". I'm more or less OK with that as an answer to UFS, which in Leopard you are not permitted to designate as a boot volume, and the boot loader for x86 more or less does not recognize the FS format, so it's unlikely to either have a boot cache on it, or have the HFS utilities run against it. You would probably not be happy with the fix you proposed in the radar; first, you can compare "< 0" rather than "== -1" and get the same effect, and second, for truly sparse FSs, we would need to fake up extents by iterating the emply blocks to the first non-empty block to give you an extent, and this would have to be done in the FS itself (and UFS doesn't do it). For block rather than extent based FS's, this would mean scanning the entire file length on a block by block basis. This email sent to site_archiver@lists.apple.com