[Bug 220288] New: A typo Leads to loss of all data on disk

[Bug 220288] New: A typo Leads to loss of all data on disk

[bugzilla-daemon]

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: fs_ext4@kernel-bugs.osdl.org
          Reporter: martin.vahi@softf1.com
        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.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

Re: [Bug 220288] New: A typo Leads to loss of all data on disk

[Theodore Ts'o]

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 blocks

See 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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220288

--- Comment #1 from Theodore Tso (tytso@mit.edu) ---
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 blocks

See how fsck.ext4 asks for permission before it makes any change to
the filesystem?

-- 
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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220288

--- Comment #2 from Martin Vahi (martin.vahi@softf1.com) ---
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).

-- 
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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220288

--- Comment #3 from Martin Vahi (martin.vahi@softf1.com) ---
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.

-- 
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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220288

Andreas Dilger (adilger.kernelbugzilla@dilger.ca) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adilger.kernelbugzilla@dilg
                   |                            |er.ca

--- Comment #4 from Andreas Dilger (adilger.kernelbugzilla@dilger.ca) ---
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.

-- 
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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220288

Artem S. Tashkinov (aros@gmx.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WILL_NOT_FIX

-- 
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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220288

--- Comment #5 from Artem S. Tashkinov (aros@gmx.com) ---
(In reply to Andreas Dilger from comment #4)
> 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.

-- 
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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220288

--- Comment #6 from Martin Vahi (martin.vahi@softf1.com) ---
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.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.