From patchwork Thu Aug 20 11:40:02 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Weinberger X-Patchwork-Id: 7043881 Return-Path: X-Original-To: patchwork-linux-fsdevel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 1F791C05AC for ; Thu, 20 Aug 2015 11:40:48 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 4A3DA20569 for ; Thu, 20 Aug 2015 11:40:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 605F120567 for ; Thu, 20 Aug 2015 11:40:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752063AbbHTLkc (ORCPT ); Thu, 20 Aug 2015 07:40:32 -0400 Received: from a.ns.miles-group.at ([95.130.255.143]:11949 "EHLO radon.swed.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751552AbbHTLkM (ORCPT ); Thu, 20 Aug 2015 07:40:12 -0400 Received: (qmail 11896 invoked by uid 89); 20 Aug 2015 11:40:11 -0000 Received: by simscan 1.3.1 ppid: 11891, pid: 11894, t: 0.1162s scanners: attach: 1.3.1 Received: from unknown (HELO ?10.1.1.174?) (richard@nod.at@80.110.11.170) by radon.swed.at with ESMTPA; 20 Aug 2015 11:40:10 -0000 Subject: Re: [PATCH 2/2] ubifs: Allow O_DIRECT To: dedekind1@gmail.com, Dongsheng Yang , linux-mtd@lists.infradead.org References: <1440016553-26481-1-git-send-email-richard@nod.at> <1440016553-26481-2-git-send-email-richard@nod.at> <55D542C5.6040500@cn.fujitsu.com> <1440070300.31419.202.camel@gmail.com> Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org From: Richard Weinberger X-Enigmail-Draft-Status: N1110 Message-ID: <55D5BC92.8050903@nod.at> Date: Thu, 20 Aug 2015 13:40:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <1440070300.31419.202.camel@gmail.com> Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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 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 Thanks, //richard Signed-off-by: Artem Bityutskiy --- 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,