MIME-Version: 1.0
References: <CGME20230126051713epcas1p10a9005ad21887893a486100cbbd376e5@epcas1p1.samsung.com>
 <20230126051657.163497-1-huijin.park@samsung.com> <20230126053136.GC28355@lst.de>
In-Reply-To: <20230126053136.GC28355@lst.de>
From:   Huijin Park <bbanghj.park@gmail.com>
Date:   Fri, 3 Feb 2023 03:12:41 +0900
Message-ID: <CAMy0x0n_vWQrPwtzXCQ9v_-K89nYOHWL0mUf2LGwrOONx0x5hg@mail.gmail.com>
Subject: Re: [PATCH] loop: change fsync to fdatasync when update dio
To:     Christoph Hellwig <hch@lst.de>
Cc:     Huijin Park <huijin.park@samsung.com>,
        Jens Axboe <axboe@kernel.dk>,
        Chaitanya Kulkarni <kch@nvidia.com>,
        linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, Jan 26, 2023 at 2:31 PM Christoph Hellwig <hch@lst.de> wrote:
>
> On Thu, Jan 26, 2023 at 02:16:57PM +0900, Huijin Park wrote:
> > In general, fsync has a larger overhead than fdatasync. And since the
> > dio option is for data, it seems like fdatasync is enough.
> > So this patch changes it to fdatasync which has little load relatively.
>
> The only difference is that fsync also syncs the timestamps.  So this
> change looks correct, but also a bit useless given that buffered to
> direct I/O or back changes aren't exactly a fast path.

Although the difference will be minimal, why I suggested it is because
it can reduce unnecessary metadata i/o (helpful on slow i/o devices),
and using fdatasync looked correct like your opinion.
In some environment cases, loop setup for mount is required when
application is initialized and this change will help.