Problem with fcntl/F_LOG2PHYS (was: Re: How to read files from disk directly?)
Problem with fcntl/F_LOG2PHYS (was: Re: How to read files from disk directly?)
- Subject: Problem with fcntl/F_LOG2PHYS (was: Re: How to read files from disk directly?)
- From: Stan Sieler <email@hidden>
- Date: Wed, 06 Jul 2011 17:52:15 -0700
Hi,
Someone mentioned using fcntl ( , F_LOG2PHYS) ...
out of curiosity, I experimented with it.
I noticed that it returns bad information for a very few files,
with l2p_devoffset having a value of 0xfffffffffffff000 ...
which would be one heck of a disk drive!
Has anyone successfully used fcntl/F_LOG2PHYS?
Or, can anyone shed light on why I should be getting this kind of result?
One of the failing files is a VMWare Fusion ".vmem" file ...
perhaps the file is sparse and the first page of the file isn't allocated disk storage.
(Thus, an lseek (fid, 0, SEEK_SET) would work, but an fcntl/F_LOG2PHYS would not have
valid data to return.)
But... the problem also occurs for each of the six Bitcoin "db" files (e.g., __db.001 through __db.006):
-rw------- 1 sieler staff 24576 Jul 1 18:30 __db.001
-rw------- 1 sieler staff 598016 Jul 1 18:30 __db.002
-rw------- 1 sieler staff 270336 Jul 1 18:30 __db.003
-rw------- 1 sieler staff 163840 Jul 1 18:30 __db.004
-rw------- 1 sieler staff 6316032 Jul 1 18:30 __db.005
-rw------- 1 sieler staff 49152 Jul 1 18:30 __db.006
(which are small files)
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 :)
The kernel might be doing:
case F_LOG2PHYS:
...
vp = (struct vnode *)fp->f_data;
VOP_LOCK(vp, LK_EXCLUSIVE, p);
if (VOP_OFFTOBLK(vp, fp->f_offset, &lbn))
panic("fcntl LOG2PHYS OFFTOBLK");
if (VOP_BLKTOOFF(vp, lbn, &offset))
panic("fcntl LOG2PHYS BLKTOOFF1");
error = VOP_BMAP(vp, lbn, &devvp, &bn, 0);
VOP_DEVBLOCKSIZE(devvp, &devBlockSize);
VOP_UNLOCK(vp, 0, p);
if (!error) {
l2p_struct.l2p_flags = 0; /* for now */
l2p_struct.l2p_contigbytes = 0; /* for now */
l2p_struct.l2p_devoffset = bn * devBlockSize;
l2p_struct.l2p_devoffset += fp->f_offset - offset;
error = copyout((caddr_t)&l2p_struct,
(caddr_t)uap->arg,
sizeof (l2p_struct));
which might imply that "bn" (from VOP_BMAP) is bad.
(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.)
thanks,
Stan
thanks,
Stan
_______________________________________________
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