[PATCH] [fs/9p] Add a Direct IO address_space_operation.

[PATCH] [fs/9p] Add a Direct IO address_space_operation.

[Venkateswararao Jujjuri (JV)]

The presence of v9fs_direct_IO() in the address space ops vector means
the 9P client supports direct I/O.  However, we shunt off direct
read and write requests before the VFS gets them, so this method
should never be called.

Signed-off-by: Venkateswararao Jujjuri <jvrao@linux.vnet.ibm.com>
---
 fs/9p/vfs_addr.c |   24 ++++++++++++++++++++++++
 1 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/fs/9p/vfs_addr.c b/fs/9p/vfs_addr.c
index 90e3844..fedcf90 100644
--- a/fs/9p/vfs_addr.c
+++ b/fs/9p/vfs_addr.c
@@ -154,10 +154,34 @@ static int v9fs_launder_page(struct page *page)
 	return 0;
 }
 
+/**
+ * v9fs_direct_IO - 9P address space operation for direct I/O
+ * @rw: direction (read or write)
+ * @iocb: target I/O control block
+ * @iov: array of vectors that define I/O buffer
+ * @pos: offset in file to begin the operation
+ * @nr_segs: size of iovec array
+ *
+ * The presence of this routine in the address space ops vector means
+ * the 9P client supports direct I/O.  However, we shunt off direct
+ * read and write requests before the VFS gets them, so this method
+ * should never be called.
+ */
+ssize_t v9fs_direct_IO(int rw, struct kiocb *iocb, const struct iovec *iov,
+		loff_t pos, unsigned long nr_segs)
+{
+	P9_DPRINTK(P9_DEBUG_VFS, "v9fs_direct_IO: v9fs_direct_IO (%s) "
+			"off/no(%lld/%lu) EINVAL\n",
+			iocb->ki_filp->f_path.dentry->d_name.name,
+			(long long) pos, nr_segs);
+
+	return -EINVAL;
+}
 const struct address_space_operations v9fs_addr_operations = {
       .readpage = v9fs_vfs_readpage,
       .readpages = v9fs_vfs_readpages,
       .releasepage = v9fs_release_page,
       .invalidatepage = v9fs_invalidate_page,
       .launder_page = v9fs_launder_page,
+      .direct_IO = v9fs_direct_IO,
 };
-- 
1.6.5.2

Re: [V9fs-developer] [PATCH] [fs/9p] Add a Direct IO address_space_operation.

[Eric Van Hensbergen]

Is this just adding dead-code then? (I know I'm conflicting with my no
silent errors motto -- but I'm keen to keep our line-count down)
By what path would we normally end up in this function?  If caches were enabled?

           -eric


On Tue, Aug 17, 2010 at 12:19 PM, Venkateswararao Jujjuri (JV)
<jvrao@linux.vnet.ibm.com> wrote:
> The presence of v9fs_direct_IO() in the address space ops vector means
> the 9P client supports direct I/O.  However, we shunt off direct
> read and write requests before the VFS gets them, so this method
> should never be called.
>
> Signed-off-by: Venkateswararao Jujjuri <jvrao@linux.vnet.ibm.com>
> ---
>  fs/9p/vfs_addr.c |   24 ++++++++++++++++++++++++
>  1 files changed, 24 insertions(+), 0 deletions(-)
>
> diff --git a/fs/9p/vfs_addr.c b/fs/9p/vfs_addr.c
> index 90e3844..fedcf90 100644
> --- a/fs/9p/vfs_addr.c
> +++ b/fs/9p/vfs_addr.c
> @@ -154,10 +154,34 @@ static int v9fs_launder_page(struct page *page)
>        return 0;
>  }
>
> +/**
> + * v9fs_direct_IO - 9P address space operation for direct I/O
> + * @rw: direction (read or write)
> + * @iocb: target I/O control block
> + * @iov: array of vectors that define I/O buffer
> + * @pos: offset in file to begin the operation
> + * @nr_segs: size of iovec array
> + *
> + * The presence of this routine in the address space ops vector means
> + * the 9P client supports direct I/O.  However, we shunt off direct
> + * read and write requests before the VFS gets them, so this method
> + * should never be called.
> + */
> +ssize_t v9fs_direct_IO(int rw, struct kiocb *iocb, const struct iovec *iov,
> +               loff_t pos, unsigned long nr_segs)
> +{
> +       P9_DPRINTK(P9_DEBUG_VFS, "v9fs_direct_IO: v9fs_direct_IO (%s) "
> +                       "off/no(%lld/%lu) EINVAL\n",
> +                       iocb->ki_filp->f_path.dentry->d_name.name,
> +                       (long long) pos, nr_segs);
> +
> +       return -EINVAL;
> +}
>  const struct address_space_operations v9fs_addr_operations = {
>       .readpage = v9fs_vfs_readpage,
>       .readpages = v9fs_vfs_readpages,
>       .releasepage = v9fs_release_page,
>       .invalidatepage = v9fs_invalidate_page,
>       .launder_page = v9fs_launder_page,
> +      .direct_IO = v9fs_direct_IO,
>  };
> --
> 1.6.5.2
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> V9fs-developer mailing list
> V9fs-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/v9fs-developer
>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [V9fs-developer] [PATCH] [fs/9p] Add a Direct IO address_space_operation.

[Venkateswararao Jujjuri (JV)]

Eric Van Hensbergen wrote:
> Is this just adding dead-code then? (I know I'm conflicting with my no
> silent errors motto -- but I'm keen to keep our line-count down)

Not really a dead code. if the O_DIRECT flag is set, __dentry_open() checks for
f->f_mapping->a_ops->direct_IO before proceeding with open.
In the absense of this routine, open with O_DIRECT flag fails.

> By what path would we normally end up in this function?  If caches were enabled?

If cache is enabled we use generic_file_aio_read() as aio_read() operation.
This ends up calling this new routine and fails with the error. So, until we
actually
implement a directio handle in the cached mode, there won't be a direct_IO support
in the cached mode.

generic_file_aio_read()
{
...
	if (filp->f_flags & O_DIRECT) {
		...
		...
		retval = mapping->a_ops->direct_IO(READ, iocb,
                                                        iov, pos, nr_segs);

              <<<The new routine returns error here >>>
	}
}

Will that be OK to move forwarded with directio support only for non-cached mode,
and deal with cached mode later?

Thanks,
JV

> 
>            -eric
> 
> 
> On Tue, Aug 17, 2010 at 12:19 PM, Venkateswararao Jujjuri (JV)
> <jvrao@linux.vnet.ibm.com> wrote:
>> The presence of v9fs_direct_IO() in the address space ops vector means
>> the 9P client supports direct I/O.  However, we shunt off direct
>> read and write requests before the VFS gets them, so this method
>> should never be called.
>>
>> Signed-off-by: Venkateswararao Jujjuri <jvrao@linux.vnet.ibm.com>
>> ---
>>  fs/9p/vfs_addr.c |   24 ++++++++++++++++++++++++
>>  1 files changed, 24 insertions(+), 0 deletions(-)
>>
>> diff --git a/fs/9p/vfs_addr.c b/fs/9p/vfs_addr.c
>> index 90e3844..fedcf90 100644
>> --- a/fs/9p/vfs_addr.c
>> +++ b/fs/9p/vfs_addr.c
>> @@ -154,10 +154,34 @@ static int v9fs_launder_page(struct page *page)
>>        return 0;
>>  }
>>
>> +/**
>> + * v9fs_direct_IO - 9P address space operation for direct I/O
>> + * @rw: direction (read or write)
>> + * @iocb: target I/O control block
>> + * @iov: array of vectors that define I/O buffer
>> + * @pos: offset in file to begin the operation
>> + * @nr_segs: size of iovec array
>> + *
>> + * The presence of this routine in the address space ops vector means
>> + * the 9P client supports direct I/O.  However, we shunt off direct
>> + * read and write requests before the VFS gets them, so this method
>> + * should never be called.
>> + */
>> +ssize_t v9fs_direct_IO(int rw, struct kiocb *iocb, const struct iovec *iov,
>> +               loff_t pos, unsigned long nr_segs)
>> +{
>> +       P9_DPRINTK(P9_DEBUG_VFS, "v9fs_direct_IO: v9fs_direct_IO (%s) "
>> +                       "off/no(%lld/%lu) EINVAL\n",
>> +                       iocb->ki_filp->f_path.dentry->d_name.name,
>> +                       (long long) pos, nr_segs);
>> +
>> +       return -EINVAL;
>> +}
>>  const struct address_space_operations v9fs_addr_operations = {
>>       .readpage = v9fs_vfs_readpage,
>>       .readpages = v9fs_vfs_readpages,
>>       .releasepage = v9fs_release_page,
>>       .invalidatepage = v9fs_invalidate_page,
>>       .launder_page = v9fs_launder_page,
>> +      .direct_IO = v9fs_direct_IO,
>>  };
>> --
>> 1.6.5.2
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by
>>
>> Make an app they can't live without
>> Enter the BlackBerry Developer Challenge
>> http://p.sf.net/sfu/RIM-dev2dev
>> _______________________________________________
>> V9fs-developer mailing list
>> V9fs-developer@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/v9fs-developer
>>

Re: [V9fs-developer] [PATCH] [fs/9p] Add a Direct IO address_space_operation.

[Eric Van Hensbergen]

On Mon, Aug 23, 2010 at 7:19 PM, Venkateswararao Jujjuri (JV)
<jvrao@linux.vnet.ibm.com> wrote:
>
> Eric Van Hensbergen wrote:
> > Is this just adding dead-code then? (I know I'm conflicting with my no
> > silent errors motto -- but I'm keen to keep our line-count down)
>
> Not really a dead code. if the O_DIRECT flag is set, __dentry_open() checks for
> f->f_mapping->a_ops->direct_IO before proceeding with open.
> In the absense of this routine, open with O_DIRECT flag fails.
>
> > By what path would we normally end up in this function?  If caches were enabled?
>
> If cache is enabled we use generic_file_aio_read() as aio_read() operation.
> This ends up calling this new routine and fails with the error. So, until we
> actually
> implement a directio handle in the cached mode, there won't be a direct_IO support
> in the cached mode.
>
> generic_file_aio_read()
> {
> ...
>        if (filp->f_flags & O_DIRECT) {
>                ...
>                ...
>                retval = mapping->a_ops->direct_IO(READ, iocb,
>                                                        iov, pos, nr_segs);
>
>              <<<The new routine returns error here >>>
>        }
> }
>
> Will that be OK to move forwarded with directio support only for non-cached mode,
> and deal with cached mode later?
>
> Thanks,
> JV
>

Yup - seems reasonable enough - lets just make sure we remember it
when we get the cached modes in place.  I guess this won't be a
regression even for existing cache modes because DirectIO would have
failed without the presence of this function anyways.

       -eric
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html