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: Duane Murphy <email@hidden>
- Date: Wed, 06 Jul 2011 18:23:53 -0700
F_LOG2PHYS is not available for all file systems or for all files.
For example, on NTFS volumes, very small files are actually stored in the directory database. F_LOG2PHYS cannot return anything rational for that case. Other files on NTFS work fine.
F_LOG2PHYS may not be supported on all file systems (e.g. network file systems).
On July 6, 2011, at 5:52 PM, Stan Sieler wrote:
> 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
...Duane
_______________________________________________
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