By request on #linuxfs, here is the FIEMAP spec that we used to implement
the FIEMAP support for ext4. There was an ext4 patch posted on August 29
to linux-ext4 entitled [PATCH] FIEMAP ioctl. I've asked Kalpak to post
an updated version of that patch along with the changes to the filefrag
tool
Hi Andreas,
Thanks for posting this. I believe that an interface such as FIEMAP
would be very useful to Ocfs2 as well. (I added ocfs2-devel to the e-mail)
My comments below are generally geared towards understanding the ioctl
interface.
On Mon, Oct 29, 2007 at 01:45:07PM -0600, Andreas
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
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
On Mon, Oct 29, 2007 at 01:45:07PM -0600, Andreas Dilger wrote:
By request on #linuxfs, here is the FIEMAP spec that we used to implement
the FIEMAP support for ext4. There was an ext4 patch posted on August 29
to linux-ext4 entitled [PATCH] FIEMAP ioctl.
Link:
On Oct 29, 2007 13:57 -0700, Mark Fasheh wrote:
Thanks for posting this. I believe that an interface such as FIEMAP
would be very useful to Ocfs2 as well. (I added ocfs2-devel to the e-mail)
I tried to make it as Lustre-agnostic as possible...
On Mon, Oct 29, 2007 at 01:45:07PM -0600,
On Oct 29, 2007 17:11 -0700, Mark Fasheh wrote:
On Mon, Oct 29, 2007 at 04:13:02PM -0600, Andreas Dilger wrote:
Btrfs, Ocfs2, and Gfs2 pack small amounts of user data directly in inode
blocks.
Hmm, but part of the issue would be how to request the extra data, and
what offset it
On Mon, Oct 29, 2007 at 04:13:02PM -0600, Andreas Dilger wrote:
On Oct 29, 2007 13:57 -0700, Mark Fasheh wrote:
Thanks for posting this. I believe that an interface such as FIEMAP
would be very useful to Ocfs2 as well. (I added ocfs2-devel to the e-mail)
I tried to make it as
On May 02, 2007 20:57 +1000, David Chinner wrote:
On Wed, May 02, 2007 at 10:36:12AM +0100, Anton Altaparmakov wrote:
HSM_READ is definitely _NOT_ required because all
it means is if the file is OFFLINE, bring it ONLINE and then return
the extent map.
You've got the definition of
On 3 May 2007, at 08:49, Andreas Dilger wrote:
On May 02, 2007 20:57 +1000, David Chinner wrote:
On Wed, May 02, 2007 at 10:36:12AM +0100, Anton Altaparmakov wrote:
HSM_READ is definitely _NOT_ required because all
it means is if the file is OFFLINE, bring it ONLINE and then return
the
On 2 May 2007, at 09:23, Anton Altaparmakov wrote:
On 1 May 2007, at 23:30, Andreas Dilger wrote:
On May 01, 2007 14:22 +1000, David Chinner wrote:
On Mon, Apr 30, 2007 at 04:44:01PM -0600, Andreas Dilger wrote:
Hmm, I'd thought offline would migrate to EXTENT_UNKNOWN, but
I didn't
I
On Tue, May 01, 2007 at 07:46:53PM +0100, Anton Altaparmakov wrote:
On 1 May 2007, at 15:20, David Chinner wrote:
So, either the filesystem will understand the flag or iff the
unknown flag
is in the incompat set, it will return EINVAL or else the unknown
flag will
be safely ignored.
On 2 May 2007, at 10:15, David Chinner wrote:
On Tue, May 01, 2007 at 07:46:53PM +0100, Anton Altaparmakov wrote:
On 1 May 2007, at 15:20, David Chinner wrote:
So, either the filesystem will understand the flag or iff the
unknown flag
is in the incompat set, it will return EINVAL or else
On 2 May 2007, at 10:15, David Chinner wrote:
On Tue, May 01, 2007 at 07:46:53PM +0100, Anton Altaparmakov wrote:
And all applications will run against a multitude of
kernels. So version X of the application will run on kernel 2.4.*,
2.6.*, a.b.*, etc... For future expandability of the
On Wed, May 02, 2007 at 09:23:38AM +0100, Anton Altaparmakov wrote:
On a different issue, do you think it would be worth adding an option
flags like FIEMAP_DONT_RELOCATE or something similar that would be a
compulsory flag and if set the FS is not allowed to move the file
around/change
On 2 May 2007, at 10:48, David Chinner wrote:
On Wed, May 02, 2007 at 09:23:38AM +0100, Anton Altaparmakov wrote:
On a different issue, do you think it would be worth adding an option
flags like FIEMAP_DONT_RELOCATE or something similar that would be a
compulsory flag and if set the FS is not
On Wed, May 02, 2007 at 10:36:12AM +0100, Anton Altaparmakov wrote:
On 2 May 2007, at 10:15, David Chinner wrote:
On Tue, May 01, 2007 at 07:46:53PM +0100, Anton Altaparmakov wrote:
And all applications will run against a multitude of
kernels. So version X of the application will run on
On 2 May 2007, at 11:57, David Chinner wrote:
On Wed, May 02, 2007 at 10:36:12AM +0100, Anton Altaparmakov wrote:
On 2 May 2007, at 10:15, David Chinner wrote:
On Tue, May 01, 2007 at 07:46:53PM +0100, Anton Altaparmakov wrote:
And all applications will run against a multitude of
kernels.
On Mon, Apr 30, 2007 at 09:39:06PM -0700, Nicholas Miell wrote:
On Tue, 2007-05-01 at 14:22 +1000, David Chinner wrote:
On Mon, Apr 30, 2007 at 04:44:01PM -0600, Andreas Dilger wrote:
This is actually for future use. Any flags that are added into this
range must be understood by both
On 1 May 2007, at 05:22, David Chinner wrote:
On Mon, Apr 30, 2007 at 04:44:01PM -0600, Andreas Dilger wrote:
The FIBMAP ioctl is for privileged users
only, and I wonder if FIEMAP should be the same, or at least
disallow
mapping files that the user can't access especially with
On 1 May 2007, at 15:20, David Chinner wrote:
On Mon, Apr 30, 2007 at 09:39:06PM -0700, Nicholas Miell wrote:
On Tue, 2007-05-01 at 14:22 +1000, David Chinner wrote:
On Mon, Apr 30, 2007 at 04:44:01PM -0600, Andreas Dilger wrote:
This is actually for future use. Any flags that are added into
On May 01, 2007 14:22 +1000, David Chinner wrote:
On Mon, Apr 30, 2007 at 04:44:01PM -0600, Andreas Dilger wrote:
Hmm, I'd thought offline would migrate to EXTENT_UNKNOWN, but I didn't
I disagree - why would you want to indicate the state is unknown when we know
very well that it is
On May 02, 2007 00:20 +1000, David Chinner wrote:
My point was that there is a difference between specification and
implementation - if the specification says something is compulsory,
then they must be implemented in the filesystem. This is easy
enough to ensure by code review - we don't need
On Tue, May 01, 2007 at 07:37:20PM +0100, Anton Altaparmakov wrote:
On 1 May 2007, at 05:22, David Chinner wrote:
On Mon, Apr 30, 2007 at 04:44:01PM -0600, Andreas Dilger wrote:
The FIBMAP ioctl is for privileged users
only, and I wonder if FIEMAP should be the same, or at least
On Tue, May 01, 2007 at 03:30:40PM -0700, Andreas Dilger wrote:
On May 01, 2007 14:22 +1000, David Chinner wrote:
On Mon, Apr 30, 2007 at 04:44:01PM -0600, Andreas Dilger wrote:
Hmm, I'd thought offline would migrate to EXTENT_UNKNOWN, but I didn't
I disagree - why would you want to
On Apr 19, 2007 11:54 +1000, David Chinner wrote:
struct fiemap {
__u64 fm_start; /* logical start offset of mapping (in/out) */
__u64 fm_len; /* logical length of mapping (in/out) */
__u32 fm_flags; /* FIEMAP_FLAG_* flags for request (in/out) */
On Mon, Apr 30, 2007 at 04:44:01PM -0600, Andreas Dilger wrote:
On Apr 19, 2007 11:54 +1000, David Chinner wrote:
struct fiemap {
__u64 fm_start; /* logical start offset of mapping (in/out) */
__u64 fm_len; /* logical length of mapping (in/out) */
__u32
On Apr 16, 2007 18:01 +1000, Timothy Shimmin wrote:
--On 12 April 2007 5:05:50 AM -0600 Andreas Dilger [EMAIL PROTECTED]
wrote:
struct fiemap_extent {
__u64 fe_start; /* starting offset in bytes */
__u64 fe_len; /* length in bytes */
}
struct
On Apr 16, 2007 21:22 +1000, David Chinner wrote:
On Thu, Apr 12, 2007 at 05:05:50AM -0600, Andreas Dilger wrote:
struct fiemap_extent {
__u64 fe_start; /* starting offset in bytes */
__u64 fe_len; /* length in bytes */
}
struct fiemap {
On Wed, Apr 18, 2007 at 06:21:39PM -0600, Andreas Dilger wrote:
On Apr 16, 2007 21:22 +1000, David Chinner wrote:
On Thu, Apr 12, 2007 at 05:05:50AM -0600, Andreas Dilger wrote:
struct fiemap_extent {
__u64 fe_start; /* starting offset in bytes */
__u64 fe_len;
Hi Andreas,
--On 12 April 2007 5:05:50 AM -0600 Andreas Dilger [EMAIL PROTECTED] wrote:
I'm interested in getting input for implementing an ioctl to efficiently
map file extents holes (FIEMAP) instead of looping over FIBMAP a billion
times.
...
I had come up with a plan independently and
On Thu, Apr 12, 2007 at 05:05:50AM -0600, Andreas Dilger wrote:
I'm interested in getting input for implementing an ioctl to efficiently
map file extents holes (FIEMAP) instead of looping over FIBMAP a billion
times. We already have customers with single files in the 10TB range and
we
Hi Andreas,
On 13 Apr 2007, at 05:01, Andreas Dilger wrote:
On Apr 12, 2007 12:22 +0100, Anton Altaparmakov wrote:
On 12 Apr 2007, at 12:05, Andreas Dilger wrote:
I'm interested in getting input for implementing an ioctl to
efficiently map file extents holes (FIEMAP) instead of looping
over
On Thu, Apr 12, 2007 at 05:05:50AM -0600, Andreas Dilger wrote:
struct fibmap_extent {
__u64 fe_start; /* starting offset in bytes */
__u64 fe_len; /* length in bytes */
}
struct fibmap {
struct fibmap_extent fm_start; /* offset, length
On 13 Apr 2007, at 11:15, Christoph Hellwig wrote:
On Thu, Apr 12, 2007 at 05:05:50AM -0600, Andreas Dilger wrote:
struct fibmap_extent {
__u64 fe_start; /* starting offset in bytes */
__u64 fe_len; /* length in bytes */
}
struct fibmap {
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andreas Dilger wrote:
On Apr 12, 2007 12:22 +0100, Anton Altaparmakov wrote:
This would say that the offset on disk can move at any time or that
the data is compressed or encrypted on disk thus the data is not
useful for direct disk access.
On Fri, 2007-04-13 at 12:38 +0100, Anton Altaparmakov wrote:
One addition freature from the XFS getbmapx interface we should
provide is the ability to query layout of xattrs. While other
filesystems might not have the exact xattr fork XFS has it fits
nicely into the interface. Especially
I'm interested in getting input for implementing an ioctl to efficiently
map file extents holes (FIEMAP) instead of looping over FIBMAP a billion
times. We already have customers with single files in the 10TB range and
we additionally need to get the mapping over the network so it needs to
be
Hi Andreas,
On 12 Apr 2007, at 12:05, Andreas Dilger wrote:
I'm interested in getting input for implementing an ioctl to
efficiently
map file extents holes (FIEMAP) instead of looping over FIBMAP a
billion
times. We already have customers with single files in the 10TB
range and
we
On Thu, 2007-04-12 at 05:05 -0600, Andreas Dilger wrote:
I'm interested in getting input for implementing an ioctl to efficiently
map file extents holes (FIEMAP) instead of looping over FIBMAP a billion
times. We already have customers with single files in the 10TB range and
we additionally
On Apr 12, 2007 12:22 +0100, Anton Altaparmakov wrote:
On 12 Apr 2007, at 12:05, Andreas Dilger wrote:
I'm interested in getting input for implementing an ioctl to
efficiently map file extents holes (FIEMAP) instead of looping
over FIBMAP a billion times. We already have customers with
41 matches
Mail list logo