| Message ID | 55D5BC92.8050903@nod.at (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-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 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-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/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-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 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-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/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-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-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/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-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Brian Norris <computersforpeace@gmail.com> writes: > 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). Even if it wasn't a test suite it should still fail. Either the fs supports O_DIRECT or it doesn't. Right now, the only way an application can figure this out is to try an open and see if it fails. Don't break that. Cheers, Jeff -- 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 Mon, Aug 24, 2015 at 01:19:24PM -0400, Jeff Moyer wrote: > Brian Norris <computersforpeace@gmail.com> writes: > > > 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). > > Even if it wasn't a test suite it should still fail. Either the fs > supports O_DIRECT or it doesn't. Right now, the only way an application > can figure this out is to try an open and see if it fails. Don't break > that. Who cares how a filesystem implements O_DIRECT as long as it does not corrupt data? ext3 fell back to buffered IO in many situations, yet the only complaints about that were performance. IOWs, it's long been true that if the user cares about O_DIRECT *performance* then they have to be careful about their choice of filesystem. But if it's only 5 lines of code per filesystem to support O_DIRECT *correctly* via buffered IO, then exactly why should userspace have to jump through hoops to explicitly handle open(O_DIRECT) failure? Especially when you consider that all they can do is fall back to buffered IO themselves.... Cheers, Dave.
On Tue, Aug 25, 2015 at 09:46:11AM +1000, Dave Chinner wrote: > On Mon, Aug 24, 2015 at 01:19:24PM -0400, Jeff Moyer wrote: > > Brian Norris <computersforpeace@gmail.com> writes: > > > > > 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). > > > > Even if it wasn't a test suite it should still fail. Either the fs > > supports O_DIRECT or it doesn't. Right now, the only way an application > > can figure this out is to try an open and see if it fails. Don't break > > that. > > Who cares how a filesystem implements O_DIRECT as long as it does > not corrupt data? ext3 fell back to buffered IO in many situations, > yet the only complaints about that were performance. IOWs, it's long been > true that if the user cares about O_DIRECT *performance* then they > have to be careful about their choice of filesystem. > > But if it's only 5 lines of code per filesystem to support O_DIRECT > *correctly* via buffered IO, then exactly why should userspace have > to jump through hoops to explicitly handle open(O_DIRECT) failure? > Especially when you consider that all they can do is fall back to > buffered IO themselves.... This is what btrfs already does for O_DIRECT plus compressed, or other cases where people don't want their applications to break on top of new features that aren't quite compatible with it. -chris -- 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 Mon, 2015-08-24 at 21:28 -0400, Chris Mason wrote: > This is what btrfs already does for O_DIRECT plus compressed, or > other > cases where people don't want their applications to break on top of > new > features that aren't quite compatible with it. I do not know how much of direct IO we can do in UBIFS - we have compression too, there is not block layer under us. But someone should try and see what could be done. 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/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,