lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071029224011.GC28607@ca-server1.us.oracle.com>
Date:	Mon, 29 Oct 2007 15:40:11 -0700
From:	Mark Fasheh <mark.fasheh@...cle.com>
To:	linux-fsdevel@...r.kernel.org, David Chinner <dgc@....com>,
	linux-ext4@...r.kernel.org, xfs@....sgi.com, hch@...radead.org,
	Anton Altaparmakov <aia21@....ac.uk>,
	Mike Waychison <mikew@...gle.com>, ocfs2-devel@....oracle.com
Subject: Re: [RFC] add FIEMAP ioctl to efficiently map file allocation

On Mon, Oct 29, 2007 at 04:29:07PM -0600, Andreas Dilger wrote:
> On Oct 29, 2007  16:13 -0600, Andreas Dilger wrote:
> > On Oct 29, 2007  13:57 -0700, Mark Fasheh wrote:
> > > I'm a little bit confused by fe_offset. Is it a physical offset, or a
> > > logical offset? The reason I ask is that your description above says "FIEMAP
> > > ioctl will return the logical to physical mapping for the extent that
> > > contains the specified logical byte address." Which seems to imply physical,
> > > but your math to get to the next logical start in a very fragmented file,
> > > implies that fe_offset is a logical offset:
> > > 
> > >        fm_start = fm_extents[fm_extent_count - 1].fe_offset +
> > >                          fm_extents[fm_extent_count - 1].fe_length + 1; 
> > 
> > Note the distinction between "fe_offset" (which is a physical offset for
> > a single extent) and "fm_offset" (which is a logical offset for that file).
> 
> Actually, that is completely bunk.  What it should say is something like:
> "filefrag can easily call the FIEMAP ioctls repeatedly using the returned
> fm_start and fm_length as the start offset for the next ioctl:
> 
>         fiemap.fm_start = fiemap.fm_start + fiemap.fm_length + 1;

Yeah - that's where I was going with my question. This is much more clear
now, thanks.
	--Mark

--
Mark Fasheh
Senior Software Developer, Oracle
mark.fasheh@...cle.com
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ