[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <YQCDZgZMf1Qfsvah@mit.edu>
Date: Tue, 27 Jul 2021 18:06:30 -0400
From: "Theodore Ts'o" <tytso@....edu>
To: Andreas Dilger <adilger@...ger.ca>
Cc: Mike Fleetwood <mike.fleetwood@...glemail.com>,
Reindl Harald <h.reindl@...lounge.net>,
linux-ext4@...r.kernel.org, "Darrick J. Wong" <djwong@...nel.org>
Subject: Re: Is labelling a mounted ext2/3/4 file system safe and supported?
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
Powered by blists - more mailing lists