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
I tried to make it as Lustre-agnostic as possible... 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
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 towar
Link: http://marc.info/?l=linux-ext4&m=118838241209683&w=2 That's a very ext4 specific ioctl interface. Can we get this made generic like the FIBMAP interface so we don't have to replicate all the co
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 n
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@xxxxxxxxxx
IMHO, your description succeeded at that. I'm hoping that the final patch can have mostly generic code, like FIBMAP does today. Oh, ok great - I was primarily looking for a way to say "there's alloca
Oh, I was confused as to what you are asking. Mapping in-inode data is just fine using the existing interface. The byte offset of the data is given, and the "FIEMAP_EXTENT_NO_DIRECT" flag is set to i
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
I tried to make it as Lustre-agnostic as possible... 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
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 towar
Link: http://marc.info/?l=linux-ext4&m=118838241209683&w=2 That's a very ext4 specific ioctl interface. Can we get this made generic like the FIBMAP interface so we don't have to replicate all the co
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 n
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@xxxxxxxxxx
IMHO, your description succeeded at that. I'm hoping that the final patch can have mostly generic code, like FIBMAP does today. Oh, ok great - I was primarily looking for a way to say "there's alloca
Oh, I was confused as to what you are asking. Mapping in-inode data is just fine using the existing interface. The byte offset of the data is given, and the "FIEMAP_EXTENT_NO_DIRECT" flag is set to i
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 eno
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,
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:01P
What you seem to be missing about my proposal is that the FLAG_INCOMPAT is for future use by that part of the specification we haven't thought of yet... Having COMPAT/INCOMPAT flags has been very use