Re: Sparse files on Mac
Re: Sparse files on Mac
- Subject: Re: Sparse files on Mac
- From: Terry Lambert <email@hidden>
- Date: Tue, 11 Dec 2007 14:44:14 -0800
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.
-- 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