Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1210014 > unrolled thread

[PATCH 2/2] ubifs: Allow O_DIRECT

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH 2/2] ubifs: Allow O_DIRECT Richard Weinberger <richard@nod.at> - 2015-08-19 22:40 +0200
    Re: [PATCH 2/2] ubifs: Allow O_DIRECT Dongsheng Yang <yangds.fnst@cn.fujitsu.com> - 2015-08-20 05:10 +0200
      Re: [PATCH 2/2] ubifs: Allow O_DIRECT Richard Weinberger <richard@nod.at> - 2015-08-20 08:50 +0200
        Re: [PATCH 2/2] ubifs: Allow O_DIRECT Dongsheng Yang <yangds.fnst@cn.fujitsu.com> - 2015-08-20 09:30 +0200
      Re: [PATCH 2/2] ubifs: Allow O_DIRECT Artem Bityutskiy <dedekind1@gmail.com> - 2015-08-20 13:40 +0200
        Re: [PATCH 2/2] ubifs: Allow O_DIRECT Richard Weinberger <richard@nod.at> - 2015-08-20 13:50 +0200
          Re: [PATCH 2/2] ubifs: Allow O_DIRECT Artem Bityutskiy <dedekind1@gmail.com> - 2015-08-20 14:40 +0200
            Re: [PATCH 2/2] ubifs: Allow O_DIRECT Artem Bityutskiy <dedekind1@gmail.com> - 2015-08-24 09:20 +0200
              Re: [PATCH 2/2] ubifs: Allow O_DIRECT Dongsheng Yang <yangds.fnst@cn.fujitsu.com> - 2015-08-24 09:30 +0200
              Re: [PATCH 2/2] ubifs: Allow O_DIRECT Dongsheng Yang <yangds.fnst@cn.fujitsu.com> - 2015-08-24 09:30 +0200
                Re: [PATCH 2/2] ubifs: Allow O_DIRECT Christoph Hellwig <hch@infradead.org> - 2015-08-24 10:10 +0200
          Re: [PATCH 2/2] ubifs: Allow O_DIRECT Brian Norris <computersforpeace@gmail.com> - 2015-08-20 23:00 +0200
            Re: [PATCH 2/2] ubifs: Allow O_DIRECT Artem Bityutskiy <dedekind1@gmail.com> - 2015-08-24 09:20 +0200
              Re: [PATCH 2/2] ubifs: Allow O_DIRECT Christoph Hellwig <hch@infradead.org> - 2015-08-24 10:00 +0200
                Re: [PATCH 2/2] ubifs: Allow O_DIRECT Christoph Hellwig <hch@infradead.org> - 2015-08-24 10:10 +0200
                  Re: [PATCH 2/2] ubifs: Allow O_DIRECT Dongsheng Yang <yangds.fnst@cn.fujitsu.com> - 2015-08-24 10:10 +0200
                  Re: [PATCH 2/2] ubifs: Allow O_DIRECT Richard Weinberger <richard@nod.at> - 2015-08-24 11:40 +0200
                  Re: [PATCH 2/2] ubifs: Allow O_DIRECT Artem Bityutskiy <dedekind1@gmail.com> - 2015-08-24 11:40 +0200
                Re: [PATCH 2/2] ubifs: Allow O_DIRECT Artem Bityutskiy <dedekind1@gmail.com> - 2015-08-24 10:10 +0200
              Re: [PATCH 2/2] ubifs: Allow O_DIRECT Brian Norris <computersforpeace@gmail.com> - 2015-08-24 18:20 +0200
                Re: [PATCH 2/2] ubifs: Allow O_DIRECT Jeff Moyer <jmoyer@redhat.com> - 2015-08-24 19:20 +0200
                  Re: [PATCH 2/2] ubifs: Allow O_DIRECT Dave Chinner <david@fromorbit.com> - 2015-08-25 01:50 +0200
                    Re: [PATCH 2/2] ubifs: Allow O_DIRECT Chris Mason <clm@fb.com> - 2015-08-25 03:30 +0200
                      Re: [PATCH 2/2] ubifs: Allow O_DIRECT Artem Bityutskiy <dedekind1@gmail.com> - 2015-08-25 17:50 +0200
                    Re: [PATCH 2/2] ubifs: Allow O_DIRECT Jeff Moyer <jmoyer@redhat.com> - 2015-08-25 16:10 +0200
                      Re: [PATCH 2/2] ubifs: Allow O_DIRECT Jeff Moyer <jmoyer@redhat.com> - 2015-08-25 16:20 +0200
                      Re: [PATCH 2/2] ubifs: Allow O_DIRECT Chris Mason <clm@fb.com> - 2015-08-25 16:20 +0200
    Re: [PATCH 2/2] ubifs: Allow O_DIRECT Artem Bityutskiy <dedekind1@gmail.com> - 2015-08-20 13:30 +0200

Page 1 of 2  [1] 2  Next page →

#1210014 — [PATCH 2/2] ubifs: Allow O_DIRECT

Currently UBIFS does not support direct IO, but some applications
blindly use the O_DIRECT flag.
Instead of failing upon open() we can do better and fall back
to buffered IO.

Cc: Dongsheng Yang <yangds.fnst@cn.fujitsu.com>
Cc: dedekind1@gmail.com
Suggested-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
---
 fs/ubifs/file.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/fs/ubifs/file.c b/fs/ubifs/file.c
index a3dfe2a..a61fe86 100644
--- a/fs/ubifs/file.c
+++ b/fs/ubifs/file.c
@@ -1540,6 +1540,15 @@ static int ubifs_file_mmap(struct file *file, struct vm_area_struct *vma)
 	return 0;
 }
 
+/*
+ * For now fall back to buffered IO.
+ */
+static ssize_t ubifs_direct_IO(struct kiocb *iocb, struct iov_iter *iter,
+				   loff_t offset)
+{
+	return 0;
+}
+
 const struct address_space_operations ubifs_file_address_operations = {
 	.readpage       = ubifs_readpage,
 	.writepage      = ubifs_writepage,
@@ -1548,6 +1557,7 @@ const struct address_space_operations ubifs_file_address_operations = {
 	.invalidatepage = ubifs_invalidatepage,
 	.set_page_dirty = ubifs_set_page_dirty,
 	.releasepage    = ubifs_releasepage,
+	.direct_IO	= ubifs_direct_IO,
 };
 
 const struct inode_operations ubifs_file_inode_operations = {
-- 
1.8.4.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1210124

On 08/20/2015 04:35 AM, Richard Weinberger wrote:
> Currently UBIFS does not support direct IO, but some applications
> blindly use the O_DIRECT flag.
> Instead of failing upon open() we can do better and fall back
> to buffered IO.

Hmmmm, to be honest, I am not sure we have to do it as Dave
suggested. I think that's just a work-around for current fstests.

IMHO, perform a buffered IO when user request direct IO without
any warning sounds not a good idea. Maybe adding a warning would
make it better.

I think we need more discussion about AIO&DIO in ubifs, and actually
I have a plan for it. But I have not listed the all cons and pros of
it so far.

Artem, what's your opinion?

Yang
>
> Cc: Dongsheng Yang <yangds.fnst@cn.fujitsu.com>
> Cc: dedekind1@gmail.com
> Suggested-by: Dave Chinner <david@fromorbit.com>
> Signed-off-by: Richard Weinberger <richard@nod.at>
> ---
>   fs/ubifs/file.c | 10 ++++++++++
>   1 file changed, 10 insertions(+)
>
> diff --git a/fs/ubifs/file.c b/fs/ubifs/file.c
> index a3dfe2a..a61fe86 100644
> --- a/fs/ubifs/file.c
> +++ b/fs/ubifs/file.c
> @@ -1540,6 +1540,15 @@ static int ubifs_file_mmap(struct file *file, struct vm_area_struct *vma)
>   	return 0;
>   }
>
> +/*
> + * For now fall back to buffered IO.
> + */
> +static ssize_t ubifs_direct_IO(struct kiocb *iocb, struct iov_iter *iter,
> +				   loff_t offset)
> +{
> +	return 0;
> +}
> +
>   const struct address_space_operations ubifs_file_address_operations = {
>   	.readpage       = ubifs_readpage,
>   	.writepage      = ubifs_writepage,
> @@ -1548,6 +1557,7 @@ const struct address_space_operations ubifs_file_address_operations = {
>   	.invalidatepage = ubifs_invalidatepage,
>   	.set_page_dirty = ubifs_set_page_dirty,
>   	.releasepage    = ubifs_releasepage,
> +	.direct_IO	= ubifs_direct_IO,
>   };
>
>   const struct inode_operations ubifs_file_inode_operations = {
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1210194

Yang, (Sorry if I've used your last name lately)

Am 20.08.2015 um 05:00 schrieb Dongsheng Yang:
> On 08/20/2015 04:35 AM, Richard Weinberger wrote:
>> Currently UBIFS does not support direct IO, but some applications
>> blindly use the O_DIRECT flag.
>> Instead of failing upon open() we can do better and fall back
>> to buffered IO.
> 
> Hmmmm, to be honest, I am not sure we have to do it as Dave
> suggested. I think that's just a work-around for current fstests.
> 
> IMHO, perform a buffered IO when user request direct IO without
> any warning sounds not a good idea. Maybe adding a warning would
> make it better.

Well, how would you inform the user?
A printk() to dmesg is useless are the vast majority of open()
callers do not check dmesg... :)

Major filesystems implement ->direct_IO these days and having
a "return 0"-stub seems to be legit.
For example exofs does too. So, I really don't consider it a work around.

> I think we need more discussion about AIO&DIO in ubifs, and actually
> I have a plan for it. But I have not listed the all cons and pros of
> it so far.

Sure, having a real ->direct_IO would be be best solution.
My patch won't block this.

Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1210231

On 08/20/2015 02:42 PM, Richard Weinberger wrote:
> Yang, (Sorry if I've used your last name lately)

Haha, that's fine. My friends in China all call me Dongsheng. :)
>
> Am 20.08.2015 um 05:00 schrieb Dongsheng Yang:
>> On 08/20/2015 04:35 AM, Richard Weinberger wrote:
>>> Currently UBIFS does not support direct IO, but some applications
>>> blindly use the O_DIRECT flag.
>>> Instead of failing upon open() we can do better and fall back
>>> to buffered IO.
>>
>> Hmmmm, to be honest, I am not sure we have to do it as Dave
>> suggested. I think that's just a work-around for current fstests.
>>
>> IMHO, perform a buffered IO when user request direct IO without
>> any warning sounds not a good idea. Maybe adding a warning would
>> make it better.
>
> Well, how would you inform the user?
> A printk() to dmesg is useless are the vast majority of open()
> callers do not check dmesg... :)
>
> Major filesystems implement ->direct_IO these days and having
> a "return 0"-stub seems to be legit.
> For example exofs does too. So, I really don't consider it a work around.

Hmmm, then I am okey with this idea now.
>
>> I think we need more discussion about AIO&DIO in ubifs, and actually
>> I have a plan for it. But I have not listed the all cons and pros of
>> it so far.
>
> Sure, having a real ->direct_IO would be be best solution.
> My patch won't block this.

Yes, agree. So let's return 0 currently.

Yang
>
> Thanks,
> //richard
> .
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1210442

On Thu, 2015-08-20 at 11:00 +0800, Dongsheng Yang wrote:
> On 08/20/2015 04:35 AM, Richard Weinberger wrote:
> > Currently UBIFS does not support direct IO, but some applications
> > blindly use the O_DIRECT flag.
> > Instead of failing upon open() we can do better and fall back
> > to buffered IO.
> 
> Hmmmm, to be honest, I am not sure we have to do it as Dave
> suggested. I think that's just a work-around for current fstests.
> 
> IMHO, perform a buffered IO when user request direct IO without
> any warning sounds not a good idea. Maybe adding a warning would
> make it better.
> 
> I think we need more discussion about AIO&DIO in ubifs, and actually
> I have a plan for it. But I have not listed the all cons and pros of
> it so far.
> 
> Artem, what's your opinion?

Yes, this is my worry too.

Basically, we need to see what is the "common practice" here, and
follow it. This requires a small research. What would be the most
popular Linux FS which does not support direct I/O? Can we check what
it does?

Artem.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1210443

Artem,

Am 20.08.2015 um 13:31 schrieb Artem Bityutskiy:
> On Thu, 2015-08-20 at 11:00 +0800, Dongsheng Yang wrote:
>> On 08/20/2015 04:35 AM, Richard Weinberger wrote:
>>> Currently UBIFS does not support direct IO, but some applications
>>> blindly use the O_DIRECT flag.
>>> Instead of failing upon open() we can do better and fall back
>>> to buffered IO.
>>
>> Hmmmm, to be honest, I am not sure we have to do it as Dave
>> suggested. I think that's just a work-around for current fstests.
>>
>> IMHO, perform a buffered IO when user request direct IO without
>> any warning sounds not a good idea. Maybe adding a warning would
>> make it better.
>>
>> I think we need more discussion about AIO&DIO in ubifs, and actually
>> I have a plan for it. But I have not listed the all cons and pros of
>> it so far.
>>
>> Artem, what's your opinion?
> 
> Yes, this is my worry too.
> 
> Basically, we need to see what is the "common practice" here, and
> follow it. This requires a small research. What would be the most
> popular Linux FS which does not support direct I/O? Can we check what
> it does?

All popular filesystems seem to support direct IO.
That's the problem, application do not expect O_DIRECT to fail.

My intention was to do it like exofs:

commit d83c7eb65d9bf0a57e7d5ed87a5bd8e5ea6b1fb6
Author: Boaz Harrosh <bharrosh@panasas.com>
Date:   Mon Jan 13 23:45:43 2014 +0200

    exofs: Allow O_DIRECT open

    With this minimal do nothing patch an application can open O_DIRECT
    and then actually do buffered sync IO instead. But the aio API is
    supported which is a good thing

    Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>

diff --git a/fs/exofs/inode.c b/fs/exofs/inode.c
index a52a5d2..7e7ba9a 100644
--- a/fs/exofs/inode.c
+++ b/fs/exofs/inode.c
@@ -961,6 +961,14 @@ static void exofs_invalidatepage(struct page *page, unsigned int offset,
 	WARN_ON(1);
 }

+
+ /* TODO: Should be easy enough to do proprly */
+static ssize_t exofs_direct_IO(int rw, struct kiocb *iocb,
+		const struct iovec *iov, loff_t offset, unsigned long nr_segs)
+{
+	return 0;
+}
+
 const struct address_space_operations exofs_aops = {
 	.readpage	= exofs_readpage,
 	.readpages	= exofs_readpages,
@@ -974,7 +982,7 @@ const struct address_space_operations exofs_aops = {

 	/* Not implemented Yet */
 	.bmap		= NULL, /* TODO: use osd's OSD_ACT_READ_MAP */
-	.direct_IO	= NULL, /* TODO: Should be trivial to do */
+	.direct_IO	= exofs_direct_IO,

 	/* With these NULL has special meaning or default is not exported */
 	.get_xip_mem	= NULL,

Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1210472

On Thu, 2015-08-20 at 13:40 +0200, Richard Weinberger wrote:
> > Basically, we need to see what is the "common practice" here, and
> > follow it. This requires a small research. What would be the most
> > popular Linux FS which does not support direct I/O? Can we check 
> > what
> > it does?
> 
> All popular filesystems seem to support direct IO.
> That's the problem, application do not expect O_DIRECT to fail.
> 
> My intention was to do it like exofs:

Fair enough, thanks!

Signed-off-by: Artem Bityutskiy <artem.bityutskiy@intel.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1211846

On Thu, 2015-08-20 at 15:34 +0300, Artem Bityutskiy wrote:
> On Thu, 2015-08-20 at 13:40 +0200, Richard Weinberger wrote:
> > > Basically, we need to see what is the "common practice" here, and
> > > follow it. This requires a small research. What would be the most
> > > popular Linux FS which does not support direct I/O? Can we check 
> > > what
> > > it does?
> > 
> > All popular filesystems seem to support direct IO.
> > That's the problem, application do not expect O_DIRECT to fail.
> > 
> > My intention was to do it like exofs:
> 
> Fair enough, thanks!
> 
> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@intel.com>

Richard, you mention this was suggested by Dave, could you please pint
to the discussion, if possible?

Artem.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1211861

On 08/24/2015 03:17 PM, Dongsheng Yang wrote:
> On 08/24/2015 03:18 PM, Artem Bityutskiy wrote:
>> On Thu, 2015-08-20 at 15:34 +0300, Artem Bityutskiy wrote:
>>> On Thu, 2015-08-20 at 13:40 +0200, Richard Weinberger wrote:
>>>>> Basically, we need to see what is the "common practice" here, and
>>>>> follow it. This requires a small research. What would be the most
>>>>> popular Linux FS which does not support direct I/O? Can we check
>>>>> what
>>>>> it does?
>>>>
>>>> All popular filesystems seem to support direct IO.
>>>> That's the problem, application do not expect O_DIRECT to fail.
>>>>
>>>> My intention was to do it like exofs:
>>>
>>> Fair enough, thanks!
>>>
>>> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@intel.com>
>>
>> Richard, you mention this was suggested by Dave, could you please pint
>> to the discussion, if possible?
>
> http://lists.infradead.org/pipermail/linux-mtd/2015-August/060702.html
>
> That's in a discussion I want to introduce ubifs into xfstests.

And Artem, I cc-ed that discussion to you, maybe you can find it in your
Inbox.
>
> Yang
>>
>> Artem.
>> --
>> 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
>> .
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> .
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1211862

On 08/24/2015 03:18 PM, Artem Bityutskiy wrote:
> On Thu, 2015-08-20 at 15:34 +0300, Artem Bityutskiy wrote:
>> On Thu, 2015-08-20 at 13:40 +0200, Richard Weinberger wrote:
>>>> Basically, we need to see what is the "common practice" here, and
>>>> follow it. This requires a small research. What would be the most
>>>> popular Linux FS which does not support direct I/O? Can we check
>>>> what
>>>> it does?
>>>
>>> All popular filesystems seem to support direct IO.
>>> That's the problem, application do not expect O_DIRECT to fail.
>>>
>>> My intention was to do it like exofs:
>>
>> Fair enough, thanks!
>>
>> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@intel.com>
>
> Richard, you mention this was suggested by Dave, could you please pint
> to the discussion, if possible?

http://lists.infradead.org/pipermail/linux-mtd/2015-August/060702.html

That's in a discussion I want to introduce ubifs into xfstests.

Yang
>
> Artem.
> --
> 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
> .
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1211884

On Mon, Aug 24, 2015 at 03:17:10PM +0800, Dongsheng Yang wrote:
> >Richard, you mention this was suggested by Dave, could you please pint
> >to the discussion, if possible?
> 
> http://lists.infradead.org/pipermail/linux-mtd/2015-August/060702.html
> 
> That's in a discussion I want to introduce ubifs into xfstests.

FYI, xfstests is a test suite, _not_ an application.  Adding O_DIRECT
just for xfstests is utterly dumb and suggeting that is even dumber.

xfstests should check for supported features, and skip tests that use
it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1210729

Pardon the innocent bystander's comment, but:

On Thu, Aug 20, 2015 at 01:40:02PM +0200, Richard Weinberger wrote:
> Am 20.08.2015 um 13:31 schrieb Artem Bityutskiy:
> > On Thu, 2015-08-20 at 11:00 +0800, Dongsheng Yang wrote:
> >> On 08/20/2015 04:35 AM, Richard Weinberger wrote:
> >>> Currently UBIFS does not support direct IO, but some applications
> >>> blindly use the O_DIRECT flag.
> >>> Instead of failing upon open() we can do better and fall back
> >>> to buffered IO.
> >>
> >> Hmmmm, to be honest, I am not sure we have to do it as Dave
> >> suggested. I think that's just a work-around for current fstests.
> >>
> >> IMHO, perform a buffered IO when user request direct IO without
> >> any warning sounds not a good idea. Maybe adding a warning would
> >> make it better.
> >>
> >> I think we need more discussion about AIO&DIO in ubifs, and actually
> >> I have a plan for it. But I have not listed the all cons and pros of
> >> it so far.
> >>
> >> Artem, what's your opinion?
> > 
> > Yes, this is my worry too.
> > 
> > Basically, we need to see what is the "common practice" here, and
> > follow it. This requires a small research. What would be the most
> > popular Linux FS which does not support direct I/O? Can we check what
> > it does?
> 
> All popular filesystems seem to support direct IO.
> That's the problem, application do not expect O_DIRECT to fail.

Why can't we just suggest fixing the applications? The man pages for
O_DIRECT clearly document the EINVAL return code:

  EINVAL The filesystem does not support the O_DIRECT flag. See NOTES
  for more information.

and under NOTES:

  O_DIRECT  support  was added under Linux in kernel version 2.4.10.
  Older Linux kernels simply ignore this flag.  Some filesystems may not
  implement the flag and open() will fail with EINVAL if it is used.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1211844

On Thu, 2015-08-20 at 13:49 -0700, Brian Norris wrote:
> Pardon the innocent bystander's comment, but:
> 
> On Thu, Aug 20, 2015 at 01:40:02PM +0200, Richard Weinberger wrote:
> > Am 20.08.2015 um 13:31 schrieb Artem Bityutskiy:
> > > On Thu, 2015-08-20 at 11:00 +0800, Dongsheng Yang wrote:
> > > > On 08/20/2015 04:35 AM, Richard Weinberger wrote:
> > > > > Currently UBIFS does not support direct IO, but some
> > > > > applications
> > > > > blindly use the O_DIRECT flag.
> > > > > Instead of failing upon open() we can do better and fall back
> > > > > to buffered IO.
> > > > 
> > > > Hmmmm, to be honest, I am not sure we have to do it as Dave
> > > > suggested. I think that's just a work-around for current
> > > > fstests.
> > > > 
> > > > IMHO, perform a buffered IO when user request direct IO without
> > > > any warning sounds not a good idea. Maybe adding a warning
> > > > would
> > > > make it better.
> > > > 
> > > > I think we need more discussion about AIO&DIO in ubifs, and
> > > > actually
> > > > I have a plan for it. But I have not listed the all cons and
> > > > pros of
> > > > it so far.
> > > > 
> > > > Artem, what's your opinion?
> > > 
> > > Yes, this is my worry too.
> > > 
> > > Basically, we need to see what is the "common practice" here, and
> > > follow it. This requires a small research. What would be the most
> > > popular Linux FS which does not support direct I/O? Can we check
> > > what
> > > it does?
> > 
> > All popular filesystems seem to support direct IO.
> > That's the problem, application do not expect O_DIRECT to fail.
> 
> Why can't we just suggest fixing the applications? The man pages for
> O_DIRECT clearly document the EINVAL return code:
> 
>   EINVAL The filesystem does not support the O_DIRECT flag. See NOTES
>   for more information.
> 
> and under NOTES:
> 
>   O_DIRECT  support  was added under Linux in kernel version 2.4.10.
>   Older Linux kernels simply ignore this flag.  Some filesystems may
> not
>   implement the flag and open() will fail with EINVAL if it is used.

That's an option.

When writing the code, we were defensive and preferred to error out for
everything we do not support. This is generally a good SW engineering
practice.

Now, some user-space fails when direct I/O is not supported. We can
chose to fake direct I/O or fix user-space. The latter seems to be the
preferred course of actions, and you are correctly pointing the man
page.

However, if

1. we are the only FS erroring out on O_DIRECT
2. other file-systems not supporting direct IO just fake it

we may just follow the crowd and fake it too.

I am kind of trusting Richard here - I assume he did the research and
the above is the case, this is why I am fine with his patch.

Does this logic seem acceptable to you? Other folk's opinion would be
great to hear.

Artem.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1211877

On Mon, Aug 24, 2015 at 10:13:25AM +0300, Artem Bityutskiy wrote:
> 1. we are the only FS erroring out on O_DIRECT
> 2. other file-systems not supporting direct IO just fake it

There are lots of file systems not supporting O_DIRECT, but ubifs might
be the most common one.  Given that O_DIRECT implementations aren't
hard, so what's holding back a real implementation?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1211880

On Mon, Aug 24, 2015 at 11:02:42AM +0300, Artem Bityutskiy wrote:
> Back when we were writing UBIFS, we did not need direct IO, so we did
> not implement it. But yes, probably someone who cares could just try
> implementing this feature.

So I think the answer here is to implement a real version insted of
adding hacks to pretend it is supported.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1211894

On 08/24/2015 04:03 PM, Christoph Hellwig wrote:
> On Mon, Aug 24, 2015 at 11:02:42AM +0300, Artem Bityutskiy wrote:
>> Back when we were writing UBIFS, we did not need direct IO, so we did
>> not implement it. But yes, probably someone who cares could just try
>> implementing this feature.
>
> So I think the answer here is to implement a real version insted of
> adding hacks to pretend it is supported.

Actually, I had a plan for it. But it's for 4.4 or 4.5 in my plan.

Yang
> .
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1212009

Am 24.08.2015 um 11:34 schrieb Artem Bityutskiy:
> On Mon, 2015-08-24 at 01:03 -0700, Christoph Hellwig wrote:
>> On Mon, Aug 24, 2015 at 11:02:42AM +0300, Artem Bityutskiy wrote:
>>> Back when we were writing UBIFS, we did not need direct IO, so we
>>> did
>>> not implement it. But yes, probably someone who cares could just
>>> try
>>> implementing this feature.
>>
>> So I think the answer here is to implement a real version insted of
>> adding hacks to pretend it is supported.
> 
> Fair enough, thank for the input!

Agreed. Let's drop this patch. :)

Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1212025

On Mon, 2015-08-24 at 01:03 -0700, Christoph Hellwig wrote:
> On Mon, Aug 24, 2015 at 11:02:42AM +0300, Artem Bityutskiy wrote:
> > Back when we were writing UBIFS, we did not need direct IO, so we
> > did
> > not implement it. But yes, probably someone who cares could just
> > try
> > implementing this feature.
> 
> So I think the answer here is to implement a real version insted of
> adding hacks to pretend it is supported.

Fair enough, thank for the input!

Artem.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1211882

On Mon, 2015-08-24 at 00:53 -0700, Christoph Hellwig wrote:
> On Mon, Aug 24, 2015 at 10:13:25AM +0300, Artem Bityutskiy wrote:
> > 1. we are the only FS erroring out on O_DIRECT
> > 2. other file-systems not supporting direct IO just fake it
> 
> There are lots of file systems not supporting O_DIRECT, but ubifs
> might
> be the most common one.  Given that O_DIRECT implementations aren't
> hard, so what's holding back a real implementation?

Back when we were writing UBIFS, we did not need direct IO, so we did
not implement it. But yes, probably someone who cares could just try
implementing this feature.

Artem.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1212330

On Mon, Aug 24, 2015 at 10:13:25AM +0300, Artem Bityutskiy wrote:
> Now, some user-space fails when direct I/O is not supported.

I think the whole argument rested on what it means when "some user space
fails"; apparently that "user space" is just a test suite (which
can/should be fixed).

> We can
> chose to fake direct I/O or fix user-space. The latter seems to be the
> preferred course of actions, and you are correctly pointing the man
> page.
> 
> However, if
> 
> 1. we are the only FS erroring out on O_DIRECT
> 2. other file-systems not supporting direct IO just fake it
> 
> we may just follow the crowd and fake it too.
> 
> I am kind of trusting Richard here - I assume he did the research and
> the above is the case, this is why I am fine with his patch.
> 
> Does this logic seem acceptable to you? Other folk's opinion would be
> great to hear.

Could work for me, though that doesn't seem ideal. Anyway, it now seems
Christopher and Richard agree with me.

Regards,
Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web