Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp4731797pxv; Tue, 27 Jul 2021 15:07:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxLTA9uFGyt9h3pqMXTZ7ZJxm5xZcpsq2jGtlUtlf6HPP8Cm3zDpsqyibiCXkgNtPv1gPhk X-Received: by 2002:a17:906:af6f:: with SMTP id os15mr6909455ejb.71.1627423672769; Tue, 27 Jul 2021 15:07:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627423672; cv=none; d=google.com; s=arc-20160816; b=dP1Avh/QOA0eDy+a2EWoTN1NnGn2qbM8RClZzgqx+eRDsZcxtJ53whP9v3YPIsSaC4 9mXfMXj3rCdXx4NW1P2tgLxJdnNsOFEP5jQcszFbLCkJHLjXfXq9FLdS6PCSlsw6MK1D badd9sagpkWJHzP1HeQzVKQFb/LFlPbwp43IElo/MoFQLZtOuqRcDyed3T0lHaBAc1Y4 Le5vmAjMcCZsfnnLZmHWI4D4jjTLVTIYQLjVc3z3/oUTNgxJffOwiO6C1VLMoVEB2DJL Kkns/KGc+/MO1rCH1sq/5VduZiP14C8oY5h/AGZMHsa8H2xRxkX74cmOr+BQt1YQfUlS lSAw== 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; bh=ZDFHV+mMbiYrD2LY8wyb711aElEo1BrxGplGLtPxXIo=; b=WkRfemHtuCOJk4vKiqiwvFnCF1NE4QP+IEBl+XTKy64H6RgBGV6KO734btjYbhRvkI pCdZVmSiWL5jOdSpO3Pjwy0k4sM5kK3OfJMf0yinnMQRvxLtLEPzPbdFVl6mW4vLOhxI lyqAl5QSWfYOBgm56dc54DJ9RWMcMyTIrehuT+5QAj7Kw9n854hsiorBUw2BpgH70v1W i1NlViRoxIW+ya9i+UnN3byeRogdRWEwL30nOTZiwE5NGw7cHSCnOtPHbr/XZGWPqy8a gls+r56n0xP7ctGbAjs3i7tEdYnKaIAFj8u5sVCreLsylX9QUI2RoR0I/gFHoxM62E6A fMwQ== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r13si3162803edo.209.2021.07.27.15.07.23; Tue, 27 Jul 2021 15:07:52 -0700 (PDT) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231814AbhG0WGw (ORCPT + 99 others); Tue, 27 Jul 2021 18:06:52 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:50537 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S231599AbhG0WGw (ORCPT ); Tue, 27 Jul 2021 18:06:52 -0400 Received: from cwcc.thunk.org (pool-72-74-133-215.bstnma.fios.verizon.net [72.74.133.215]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 16RM6VD2022989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Jul 2021 18:06:31 -0400 Received: by cwcc.thunk.org (Postfix, from userid 15806) id D848915C3DBC; Tue, 27 Jul 2021 18:06:30 -0400 (EDT) Date: Tue, 27 Jul 2021 18:06:30 -0400 From: "Theodore Ts'o" To: Andreas Dilger Cc: Mike Fleetwood , Reindl Harald , linux-ext4@vger.kernel.org, "Darrick J. Wong" Subject: Re: Is labelling a mounted ext2/3/4 file system safe and supported? Message-ID: References: <8A4E4147-0D89-4B2B-A118-F5EDABF9ABD5@dilger.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8A4E4147-0D89-4B2B-A118-F5EDABF9ABD5@dilger.ca> Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Tue, Jul 27, 2021 at 01:49:39AM -0600, Andreas Dilger wrote: > > Looking at the e2label source code, it just reads the superblock, > > updates the label and writes the super block. How is that safe and > > persistent when presumably the linux kernel has an in-memory copy of the > > superblock will be written at unmount and presumable sync. > > Currently, the in-memory superblock references the device buffer cache, > which is the same cache that is accessed when reading the block > device from userspace, so they are always consistent. > > There has been some discussion about adding ioctl() calls to update > the filesystem label, UUID, and other fields from userspace in a safer way, > but nothing has been implemented in that direction yet (possibly Darrick > had some RFC patches, but they are not landed yet). As Andreas has stated, e2fsprogs programs such as e2label and tune2fs use buffered I/O to read and write the superblock, which accesses the buffer cache, which is where the kernel's copy superblock used by the file system code is located. It's not perfect; for example an updated label written by e2label might get lost when it is overwritten by a journal replay after a system crash. But for the most part, it does work. Cheers, - Ted