Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp6023257pxb; Tue, 16 Feb 2021 13:58:00 -0800 (PST) X-Google-Smtp-Source: ABdhPJyd71gdsjGdRoml8B7zFEiTvIYX3LTduRmnpm00iCdgQ4cDcKdNunk9XU4QniKD/RmdkJIX X-Received: by 2002:aa7:c94a:: with SMTP id h10mr24112358edt.41.1613512680310; Tue, 16 Feb 2021 13:58:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613512680; cv=none; d=google.com; s=arc-20160816; b=Hq/qrvrBz5A024FAqbJNePoJxBzLj2OA6FOECG9mqzq95gJ3h+qMOytjJP9gcWAmPr TfmGvoxw/Lh6BbMeofwOOK4HthoE4H1KlIYo9jMfogsTxt22hYDSL7CWNpUyq9DDkI+s 8DsMfaI/69IAVsyMLoqkt3u8W/ads/gfmwYwhuIic18aHL19RW4YTV7WKATy0LKdPtsC UWQTjv2PphN42PAkZmnA1U0KysBWkl5hzdpkHlWd+xkg4LyWhCdYc1WTLmGdrdNJmu5F ++TcJF4NvcxqzUpbi53mzptb/m7fKJEFLrkpIXEbqYRpmxbqVVI3lGj8PD9Mq7tlmVUI mM6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=FIi6PCRiId6ElulcUf71zS/s2SqefOTIdpzwxMq2jPw=; b=AlabeeNhOoWcShZJZZsEDFcdAhXkhpvPMfV3GOhgf5mB7DQY2HHgvZZ797mp8kSqKr MyOdqGsu4KtC89zRCOQw/odhL8QYaDJVhhxUoN9ZAg62juOva0DI2MvI/IJxq7hWr575 rOw0yCnkQtzzH9nPyLVql1vMKh6mSkPEOS70vMSreHLNeDkK9UO9yep3dYVq2LOYzYLS FsAd84enshIcGZyemdCmZTW8zWSYsjiUujshT7z8UI8xrNCBosQyYuhwB6VbQQaeOBFs wCF/sl1dzKMo61jsjt+Dobl0lSvGkvo/Ix6RVMMLS1JvIbB96zBr7Qco9Js1NzRtXgu/ wGHg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=CAOPzJGc; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v16si7297862edc.108.2021.02.16.13.57.30; Tue, 16 Feb 2021 13:58:00 -0800 (PST) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=CAOPzJGc; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229722AbhBPVxN (ORCPT + 99 others); Tue, 16 Feb 2021 16:53:13 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:39912 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229577AbhBPVxN (ORCPT ); Tue, 16 Feb 2021 16:53:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1613512306; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=FIi6PCRiId6ElulcUf71zS/s2SqefOTIdpzwxMq2jPw=; b=CAOPzJGcoCMwr14toi1N4TTtkNm7Lp/Gm8IAgpff8Uttl5d/rQeWWpaGCA12oqwH3d8ghM vdik81HYN7z7t3SAFbR2QXYRySLe4Mru1wmN2Fb03r0cTHiFMLzy51p1Z/iSzE7sH99yuf 7FS4g75xPcCFYsjheCLRy3Re5GxEDYo= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-314-M938W1sPPSyDMVTIftJW1w-1; Tue, 16 Feb 2021 16:51:44 -0500 X-MC-Unique: M938W1sPPSyDMVTIftJW1w-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id DF2778030D9; Tue, 16 Feb 2021 21:51:43 +0000 (UTC) Received: from work (unknown [10.40.192.229]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2DAC15D72F; Tue, 16 Feb 2021 21:51:42 +0000 (UTC) Date: Tue, 16 Feb 2021 22:51:40 +0100 From: Lukas Czerner To: Eric Sandeen Cc: linux-ext4@vger.kernel.org Subject: Re: [PATCH] mmp: do not use O_DIRECT when working with regular file Message-ID: <20210216215140.e3yu3vl7hmcv4jss@work> References: <20210212093719.162065-1-lczerner@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Tue, Feb 16, 2021 at 03:24:00PM -0600, Eric Sandeen wrote: > On 2/12/21 3:37 AM, Lukas Czerner wrote: > > Currently the mmp block is read using O_DIRECT to avoid any caching tha > > may be done by the VM. However when working with regular files this > > creates alignment issues when the device of the host file system has > > sector size smaller than the blocksize of the file system in the file > > we're working with. > > > > This can be reproduced with t_mmp_fail test when run on the device with > > 4k sector size because the mke2fs fails when trying to read the mmp > > block. > > > > Fix it by disabling O_DIRECT when working with regular file. I don't > > think there is any risk of doing so since the file system layer, unlike > > shared block device, should guarantee cache consistency. > > > > Signed-off-by: Lukas Czerner > > --- > > lib/ext2fs/mmp.c | 22 +++++++++++----------- > > 1 file changed, 11 insertions(+), 11 deletions(-) > > > > diff --git a/lib/ext2fs/mmp.c b/lib/ext2fs/mmp.c > > index c21ae272..1ac22194 100644 > > --- a/lib/ext2fs/mmp.c > > +++ b/lib/ext2fs/mmp.c > > @@ -57,21 +57,21 @@ errcode_t ext2fs_mmp_read(ext2_filsys fs, blk64_t mmp_blk, void *buf) > > * regardless of how the io_manager is doing reads, to avoid caching of > > * the MMP block by the io_manager or the VM. It needs to be fresh. */ > > if (fs->mmp_fd <= 0) { > > + struct stat st; > > int flags = O_RDWR | O_DIRECT; > > > > -retry: > > + /* > > + * There is no reason for using O_DIRECT if we're working with > > + * regular file. Disabling it also avoids problems with > > + * alignment when the device of the host file system has sector > > + * size smaller than blocksize of the fs we're working with. > > I think the problem is when the host filesystem that contains the image is on > a device with a logical sector size which is /larger/ than the image filesystem's > block size, right? Not smaller? Yeah, it is supposed to be *larger*, of course. If it is smaller, then there is no problem. Thanks for pointing this out I'll change the comment and the description. > > Because then you might not be able to do an image-filesystem-block-aligned direct > IO on it, if it's sub-logical-block-size for the host filesystem/device, and lands > within the larger host sector at an offset? > > otherwise, this seems at least as reasonable to me as the previous tmpfs work > around, so other than the question about the comment, > > Reviewed-by: Eric Sandeen Thanks! -Lukas > > > > + */ > > + if (stat(fs->device_name, &st) == 0 && > > + S_ISREG(st.st_mode)) > > + flags &= ~O_DIRECT; > > + > > fs->mmp_fd = open(fs->device_name, flags); > > if (fs->mmp_fd < 0) { > > - struct stat st; > > - > > - /* Avoid O_DIRECT for filesystem image files if open > > - * fails, since it breaks when running on tmpfs. */ > > - if (errno == EINVAL && (flags & O_DIRECT) && > > - stat(fs->device_name, &st) == 0 && > > - S_ISREG(st.st_mode)) { > > - flags &= ~O_DIRECT; > > - goto retry; > > - } > > retval = EXT2_ET_MMP_OPEN_DIRECT; > > goto out; > > } > > >