3

I would have expected an error, sorry FS is read-only, but it is possible. This is unexpected & counter intuitive is there a reason?

Linux files 5.11.0-27-generic #29~20.04.1-Ubuntu SMP Wed Aug 11 15:58:17 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
files@files:/mnt/disk$ mount | grep /mnt/disk/005
/dev/sdh on /mnt/disk/005 type ext4 (ro,nosuid,nodev,noexec,relatime,user)
files@files:/mnt/disk$ df /mnt/disk/005/
Filesystem      1K-blocks       Used Available Use% Mounted on
/dev/sdh       7751367424 7332824836  27824876 100% /mnt/disk/005
files@files:/mnt/disk$ sudo tune2fs -r 0 /dev/sdh
tune2fs 1.45.5 (07-Jan-2020)
Setting reserved blocks count to 0
files@files:/mnt/disk$ df /mnt/disk/005/
Filesystem      1K-blocks       Used Available Use% Mounted on
/dev/sdh       7751367424 7332824836 418526204  95% /mnt/disk/005
files@files:/mnt/disk$
lithium7
  • 39
  • 1

1 Answers1

10

tune2fs never needed the filesystem to be mounted to operate. As you can see in the command, you pass a block device node (/dev/sdh) as an argument to it, not a mountpoint (/mnt/disk/005). It's similar to resize2fs and e2label.

Tom Yan
  • 715
  • 2
  • 9
  • 1
    While the read-only restriction on the *mount* has no effect here, Linux *block devices* could be marked as read-only in a similar fashion, e.g. `blockdev --setro /dev/example` restricts (future) access to the device and/or partition in question. – anx Sep 12 '21 at 05:41
  • 1
    @anx AFAIK, that may not be something that is really reliable. (I've never really digged deep into how it works, but IIRC I've seen stories about it being unexpectedly "breakable".) – Tom Yan Sep 12 '21 at 05:48
  • True. Propagation through partitions/md/rbd etc seems mostly reasonable these days, it just remains one of those little known, little used features that barely even get bugs reported. – anx Sep 12 '21 at 06:03