Hi,
Using e2label to set a new label for a mounted ext4 seems to work, but
is it a safe and supported thing to do?
Google search doesn't seem to know.
Thanks,
Mike
Am 26.07.21 um 20:45 schrieb Mike Fleetwood:
> Hi,
>
> Using e2label to set a new label for a mounted ext4 seems to work, but
> is it a safe and supported thing to do?
it is
On Mon, 26 Jul 2021 at 21:50, Reindl Harald <[email protected]> wrote:
> Am 26.07.21 um 20:45 schrieb Mike Fleetwood:
> > Hi,
> >
> > Using e2label to set a new label for a mounted ext4 seems to work, but
> > is it a safe and supported thing to do?
>
> it is
Is there some documentation which states it's safe to write to the label
while mounted?
I ask because 1) I am looking at adding such support into GParted and
2) I don't understand how it can be safe.
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.
Thanks,
Mike
On Jul 27, 2021, at 01:33, Mike Fleetwood <[email protected]> wrote:
>
> On Mon, 26 Jul 2021 at 21:50, Reindl Harald <[email protected]> wrote:
>>> Am 26.07.21 um 20:45 schrieb Mike Fleetwood:
>>> Hi,
>>>
>>> Using e2label to set a new label for a mounted ext4 seems to work, but
>>> is it a safe and supported thing to do?
>>
>> it is
>
> Is there some documentation which states it's safe to write to the label
> while mounted?
>
> I ask because 1) I am looking at adding such support into GParted and
> 2) I don't understand how it can be safe.
>
> 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).
Cheers, Andreas
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