Re: Problem with fcntl/F_LOG2PHYS (was: Re: How to read files from disk directly?)
Re: Problem with fcntl/F_LOG2PHYS (was: Re: How to read files from disk directly?)
- Subject: Re: Problem with fcntl/F_LOG2PHYS (was: Re: How to read files from disk directly?)
- From: Ken Hornstein <email@hidden>
- Date: Wed, 06 Jul 2011 23:00:59 -0400
>Has anyone successfully used fcntl/F_LOG2PHYS?
>Or, can anyone shed light on why I should be getting this kind of result?
There was some discussion about the limitations of F_LOG2PHYS. Some things
mentioned involved filesystem compression; if you look at hfs_vnop_blockmap(),
you can see that you get ENOTSUP if the file is compressed (looks like
you need to do some magic to make that happen).
>But... the problem also occurs for each of the six Bitcoin "db" files
>(e.g., __db.001 through __db.006):
Maybe there's some interoperability between F_LOG2PHYS and crazy-ass
virtual currency? :-) But seriously ... it's possible they've been
hfs+ compressed (download hfsdebug to check).
>I tested reading every byte of the __db.### files (to ensure the pages
>get allocated if they're sparse files) ... the problem remains afterwards,
>which tends to argue against sparse files being the problem.
>(Of course, if the kernel is smart enough not to allocate those pages just
>for reads, then I haven't eliminated the chance that they're sparse :)
Traditionally that wouldn't do it unless you wrote something back to those
files. But I thought I read something about HFS+ that said you never get
"true" sparse files - the kernel always writes the intervening zero blocks.
But I could be totally wrong about that.
> error = VOP_BMAP(vp, lbn, &devvp, &bn, 0);
Well, I'd look at what hfs_vnop_blockmap() is doing (that's what
VOP_BMAP() ends up calling, assuming HFS+).
>(On my HP 3000, I'd just put a breakpoint in the kernel at the equivalent
>code and run until I hit it, and then look at the kernel variables ...
>don't know if this is possible on Mac OS X.)
There's not a debugger built into the MacOS X kernel; in theory you can
rebuild the kernel with KDB support, but I've never done that myself and
I'm not sure it works; it looks to be a pain.
What does work is two-machine debugging with gdb. I do that all of the
time and it works great.
--Ken
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden