New: A typo Leads to loss of all data on disk
https://bugzilla.kernel.org/show_bug.cgi?id=220288
Bug ID: 220288
Summary: A typo Leads to loss of all data on disk
Product: File System
Version: 2.5
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P3
Component: ext4
Assignee: [email protected]
Reporter: [email protected]
Regression: No
I wanted to run
fsck.ext4 /dev/sdc1
but accidentally missed the "1" at the end by typing
fsck.ext4 /dev/sdc
and lost all data on /dev/sdc
My suggestion is that there should be some regex based test to see, if the partition name candidate ends with a base 10 digit and if it does not, then a confirmation prompt, possibly with red text, should be displayed that explains the consequences and asks for confirmation. For non-interactive use of the
fsck.ext4 /dev/sdc
there could be an extra parameter, "--skip_warning_prompts", which should be mentioned at the text of all interactive warnings so that people, who stumble on those interactive warnings do not need to look it up form fsck.ext4 man page. A temporary workaround for myself is a Bash alias that wraps the fsck.ext4, but in my opinion that's a dirty workaround and such critical warnings should be part of the tool itself, specially given how common the fsck.ext4 usage is with USB-HDDs and USB memory sticks.
Thank You for reading this bug report.
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 220288] A typo Leads to loss of all data on disk
https://bugzilla.kernel.org/show_bug.cgi?id=220288
--- Comment #1 from Theodore Tso ([email protected]) ---
I don't see how that happened. /dev/sdc has a partition table at the beginning of the disk. That partition table contains the definition of /dev/sdc1.
So if you ran "fsck.ext4 /dev/sdc" instead of "fsck.ext4 /dev/sdc1", you should have gotten something like this:
root@xfstests:~# fsck.ext4 /dev/sdb e2fsck 1.47.2-rc1 (28-Nov-2024) ext2fs_open2: Bad magic number in super-block fsck.ext4: Superblock invalid, trying backup blocks... fsck.ext4: Bad magic number in super-block while trying to open /dev/sdb
The superblock could not be read or does not describe a valid ext2/ext3/ext4 filesystem. If the device is valid and it really contains an ext2/ext3/ext4 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device> Found a gpt partition table in /dev/sdb
In any case, fsck.ext4 will not make any changes unless you give it permission by answering "yes". For example (do not try this at home, kids):
root@xfstests:~# debugfs -w -R "clri <2>" /dev/sdb1 ; debugfs -w -R "ssv
state 2" /dev/sdb1
debugfs 1.47.2-rc1 (28-Nov-2024)
debugfs 1.47.2-rc1 (28-Nov-2024)
root@xfstests:~# fsck.ext4 /dev/sdb1
e2fsck 1.47.2-rc1 (28-Nov-2024)
/dev/sdb1 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Root inode is not a directory. Clear<y>? yes
Pass 2: Checking directory structure
Entry '..' in <2>/<11> (11) has deleted/unused inode 2. Clear<y>? yes
Pass 3: Checking directory connectivity
Root inode not allocated. Allocate<y>? yes
Unconnected directory inode 11 (was in /)
Connect to /lost+found<y>? yes
/lost+found not found. Create<y>? yes
Pass 3A: Optimizing directories
Pass 4: Checking reference counts
Inode 11 ref count is 3, should be 2. Fix<y>? yes
Pass 5: Checking group summary information /dev/sdb1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdb1: 13/655360 files (0.0% non-contiguous), 67263/2620928 blocksSee how fsck.ext4 asks for permission before it makes any change to the filesystem?
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
I don't see how that happened. /dev/sdc has a partition table at the beginning of the disk. That partition table contains the definition of /dev/sdc1.
So if you ran "fsck.ext4 /dev/sdc" instead of "fsck.ext4 /dev/sdc1", you should have gotten something like this:
root@xfstests:~# fsck.ext4 /dev/sdb e2fsck 1.47.2-rc1 (28-Nov-2024) ext2fs_open2: Bad magic number in super-block fsck.ext4: Superblock invalid, trying backup blocks... fsck.ext4: Bad magic number in super-block while trying to open /dev/sdb
The superblock could not be read or does not describe a valid ext2/ext3/ext4 filesystem. If the device is valid and it really contains an ext2/ext3/ext4 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device> Found a gpt partition table in /dev/sdb
In any case, fsck.ext4 will not make any changes unless you give it permission by answering "yes". For example (do not try this at home, kids):
root@xfstests:~# debugfs -w -R "clri <2>" /dev/sdb1 ; debugfs -w -R "ssv state 2" /dev/sdb1
debugfs 1.47.2-rc1 (28-Nov-2024)
debugfs 1.47.2-rc1 (28-Nov-2024)
root@xfstests:~# fsck.ext4 /dev/sdb1
e2fsck 1.47.2-rc1 (28-Nov-2024)
/dev/sdb1 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Root inode is not a directory. Clear<y>? yes
Pass 2: Checking directory structure
Entry '..' in <2>/<11> (11) has deleted/unused inode 2. Clear<y>? yes
Pass 3: Checking directory connectivity
Root inode not allocated. Allocate<y>? yes
Unconnected directory inode 11 (was in /)
Connect to /lost+found<y>? yes
/lost+found not found. Create<y>? yes
Pass 3A: Optimizing directories
Pass 4: Checking reference counts
Inode 11 ref count is 3, should be 2. Fix<y>? yes
Pass 5: Checking group summary information /dev/sdb1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdb1: 13/655360 files (0.0% non-contiguous), 67263/2620928 blocksSee how fsck.ext4 asks for permission before it makes any change to the filesystem?
[Bug 220288] A typo Leads to loss of all data on disk
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=220288
--- Comment #2 from Martin Vahi ([email protected]) --- Thank You for the answer.
What regards to the line of thought that the behavior of fsck.ext4 is just fine as long as it asks the user for the "yes" for modifications then I think that it is a flawed line of thought, because from users point of view the fsck.ext4 is run
WHENEVER THE FILE SYSTEM DOES NOT MOUNT DUE TO DIRTY JOURNAL
and the end user will not start to do any "forensic analysis" to start thinking, if some change that the fsck.ext4 wants to do is OK or not, specially if it shows some kind of numbers as part of the question. From fsck.ext4 user's point of view the
idea is very staightforward:
if (<partition does not mount due to dirty journal>){func_run_the_fsck_ext4_and_it_better_do_its_job_without_any_mystic_number_scribble()
}
and if some question about individual inodes does appear on screen, then just press Yes to get that "nonsense" out of the way. If the text with the question were "Are You sure that You asked the fsck.ext4 to modify the right partition, because according to our suspicionns You made a typo and may be You want to consider running fsck.ext4 on '/dev/sdc1' in stead of '/dev/sdc'?", then the end user has at least some meaningful text to think about before pushing the y-button. But if the question is, as You describe, about some i-nodes, then from user's perspective those questions are expected to be pretty much the same for both, correct "/dev/sdc1" and for the typo-infected "/dev/sdc", which means that the question about some inodes does not convey the message to the end user that there could be something wrong at the call to the fsck.ext4.
Someone, who has self designed the fsck.ext4 may find the difference obvious, but for the rest of us, me being part of "the rest of us", it is NOT obvious that fsck.ext4 asks some questions about inodes if I have given device name in stead of a partition name to the fsck.ext4.
To put it in another words, it is not enough for a commonly used tool like the fsck.ext4 to work correctly according to notes at some deep documentation, but it should actually detect probable user mistakes and draw user's attention to the possible end user mistake by using a message that even that kind of an end user, who has NOT read loads of documentation and NOT intimately worked with fsck.ext4, can understand clearly. A messaging format that it asks something about inodes in one case and does not ask that in another case is not clear enough messaging format to make the user suspicious enough about possible user mistake.
Thank You for the anwer and thank You for reading my comment(s).
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 220288] A typo Leads to loss of all data on disk
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=220288
--- Comment #3 from Martin Vahi ([email protected]) ---
One more line of thought: are there any use cases for ext4 file system, where the file system is not at some partition? Like, is there any use case for giving the fsck.ext4 a device name in stead of a partition name?
Thank You for reading my comment.
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 220288] A typo Leads to loss of all data on disk
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=220288
Andreas Dilger ([email protected]) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |adilger.kernelbugzilla@dilg
| |er.ca--- Comment #4 from Andreas Dilger ([email protected]) --- It is very common in my experience that ext4 filesystems are created on whole disk devices instead of partitions when run on servers, in order to ensure the filesystem is aligned to the start on the disk and with RAID stripes.
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 220288] A typo Leads to loss of all data on disk
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=220288
Artem S. Tashkinov ([email protected]) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |WILL_NOT_FIXSignature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 220288] A typo Leads to loss of all data on disk
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=220288
--- Comment #5 from Artem S. Tashkinov ([email protected]) --- (In reply to Andreas Dilger from comment #4)
Quoted 4 lines
It is very common in my experience that ext4 filesystems are created on whole disk devices instead of partitions when run on servers, in order to ensure the filesystem is aligned to the start on the disk and with RAID stripes.
Not to mention that you can
mke2fs /tmp/random.file
and then
e2fsck /tmp/random.file
or even use a loop device with no number.
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 220288] A typo Leads to loss of all data on disk
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=220288
--- Comment #6 from Martin Vahi ([email protected]) ---
Thank You for the answers. I guess the issue is then my expectation about how the fsck.ext4 is supposed to be used. At the moment it seems to me that the solution is that people with my use case should be using a use case specific wrapper of fsck.ext4, not the very capable tool, fsck.ext4, directly. Thank You for reading my comment.
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.