Received: by 10.213.65.68 with SMTP id h4csp67185imn; Tue, 27 Mar 2018 16:40:06 -0700 (PDT) X-Google-Smtp-Source: AIpwx49rkfG7RY7W1hNwfPs+dG/5m4rzI8DGrJ6MLpLggfCEKC1v5N23KKbp6gjMRUueUlcTLFW+ X-Received: by 10.99.146.30 with SMTP id o30mr872398pgd.115.1522194006566; Tue, 27 Mar 2018 16:40:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522194006; cv=none; d=google.com; s=arc-20160816; b=r/+HH74V3RXHmPmSD+ABYwNrNTSVaIhCRWLoAjSw7NkEjDh2ahW4YhMFXkwXMnQ/vR bK5yZdouP6AxTmTfoLjxGlbUQDZPhCJVSM3ia5GNC1fxBGLbr7ObSPyvv4Gt7USPbuwN mx2+6sK1n7TKqVOUFqvxSw/vLjRGPIPq+KsBZLdrB8SMw1p0RZJFE4r+Ryrtz5O0T6B6 qhwfuSq80rTR9He83dOFkHOOtg9ELK4WbnS2+FDk0W2kgY0KxaJdH0fhb53Jit6vXPP1 G7FKabHpa4BcIq3KHS++ngidRNOyLgBBd10uR7J1VsFv5bePcntTGGJumAqpvddWnpQ7 wA+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=ahVoijgKVnU1lZXg0WyzMx1xttl6i0FnraamWmPlNXE=; b=lLcMvAAAebRXpNiVBzn8Fh8GMNkBnyq9+Xd+4NorPr01HSEXszUYEOClLZeEtgTjJY Fi7AAUeR/m0ucIQc3Sq1oTpeTgVKsxWovsUqmjb9MhJ17UaydFfTZ7PGo+O+I5tSYZN9 9KgGFy0PuBOqGLRnk7YsOrfeNKyJAM2mf7z5yD1Y7UJqVAiFMN+Rfx79m0fMIegpCgHy 7n4JEN3hzxGk39QawTUah8VoiMVUzr44LIgHi5VN9aDDFLdWxWYaZyYINYbgBjcIEjlC qOXGpdhQ1X+lqSznPxPHNUgo6X4t6eJ6AQamUAfETsyscs/B3Lh8UeP04TAHjTmGqfO8 ZS/g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w2si1512391pgt.485.2018.03.27.16.39.41; Tue, 27 Mar 2018 16:40:06 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752490AbeC0XPc (ORCPT + 99 others); Tue, 27 Mar 2018 19:15:32 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:33516 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752173AbeC0XPb (ORCPT ); Tue, 27 Mar 2018 19:15:31 -0400 Received: from akpm3.svl.corp.google.com (unknown [104.133.9.71]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 999A91458; Tue, 27 Mar 2018 23:15:30 +0000 (UTC) Date: Tue, 27 Mar 2018 16:15:29 -0700 From: Andrew Morton To: jiangyiwen Cc: Eric Van Hensbergen , Ron Minnich , Latchesar Ionkov , , , Greg Kurz Subject: Re: [V9fs-developer] [PATCH] fs/9p: don't set SB_NOATIME by default Message-Id: <20180327161529.f7d22a36ffc92dc1a3e15d92@linux-foundation.org> In-Reply-To: <5AB9A377.6080906@huawei.com> References: <5AB9A377.6080906@huawei.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 27 Mar 2018 09:50:47 +0800 jiangyiwen wrote: > User use some syscall, for example mmap(v9fs_file_mmap), it will not > update atime even if user's mnt_flags without MNT_NOATIME, because > v9fs default set SB_NOATIME in v9fs_set_super. > > For supporting access time is updated when user mount with relatime, > we should not set SB_NOATIME by default. > > ... > > --- a/fs/9p/vfs_super.c > +++ b/fs/9p/vfs_super.c > @@ -94,7 +94,7 @@ static int v9fs_set_super(struct super_block *s, void *data) > if (v9ses->cache) > sb->s_bdi->ra_pages = (VM_MAX_READAHEAD * 1024)/PAGE_SIZE; > > - sb->s_flags |= SB_ACTIVE | SB_DIRSYNC | SB_NOATIME; > + sb->s_flags |= SB_ACTIVE | SB_DIRSYNC; > if (!v9ses->cache) > sb->s_flags |= SB_SYNCHRONOUS; > So strictly speaking, this is a non-backward-compatible change, yes? Please describe the circumstances under which an existing user might be harmed by this. I *think* such harm will occur if the user was already using 'mount -o relatime', yes? They previously weren't getting relatime treatment, but now they will, and things will be a little slower. If correct, that sounds acceptable.