| Message ID | 1440016553-26481-2-git-send-email-richard@nod.at (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2015-08-19 at 22:35 +0200, 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. > > 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> Richard, The idea was to explicitly reject what we do not support. Let's say I am an app which requires O_DIRECT, and which does not want to work with non-O_DIRECT. What would I do to ensure O_DIRECT? Could you please check what other file-systems which do not support O_DIRECT do in this case? Do they also fall-back to normal IO instead of explicitly failing? If yes, we can do what is considered to be the "standard" behavior. Thanks! -- 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
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-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 = {
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(+)