Howto recover from accidental mkfs

From Ext4
(Difference between revisions)
Jump to: navigation, search
(Howmuch memory will I need ?)
(Howmuch memory will I need ?)
Line 63: Line 63:
! Disk Size !! Block Size !! e2fsprogs version !! Required memory
! Disk Size !! Block Size !! e2fsprogs version !! Required memory
| 16TiB || 4KiB || 1.42.10 || 26.4GiB
| 16TiB || 4KiB || 1.42.10 || 30.2GiB+

Latest revision as of 20:01, 26 June 2014

This document is a draft regarding advise and actions you can take after running mkfs.ext on an excisting partition. But the document might also help in general recovery.

Please also note that this document has not yet been reviewed by others.


[edit] First actions

The first step is ofcours stopping the mkfs/mke2fs action as soon as possible. Do not take any rash decisions.

[edit] If the partition is still mounted

If you managed to format drive while it was mounted (possible in some senarios) you might want to perform the following actions:

  • Execute $ mount /path -o remount,ro this should prevent any extra problems to be created
    • It could however be argued that not doing this might cause ext to rewrite certain data. But standard practise is never to write to broken FS.
  • Execute $ echo 0 > /proc/sys/vm/vfs_cache_pressure . This will ensure any information still held by the kernel to be kept.
    • Be carefull as this setting will never free vfs_cache data, and could OOM your system.
  • Run dumpe2fs on the block device.
    • You might with to use $ dumpe2fs /dev/XXX to compress the file as it can be large.
    • The manual of dumpe2fs states
      Note: When used with a  mounted  filesystem, the printed information may be old or inconsistent.
    • However since we want to old state this is a good thing.
  • Note any information you that might not be included dumpe2fs. Things that come to mind are:
    • Number of inodes.
    • Journal size.
    • Filesystem features (should be included in dumpe2fs)
    • UUID from /dev/disk/by-uuid/ (this should contain the old UUID in case it was overwritten by mkfs) (This can potentially be used for checksums later.)

Now the good news, in some senarios a large portion is still accessable.

First try obtain the files you want back first. You can use $ cat /mountpoint/dir/file (full path is required, as directories might be gone, caches might however allow you to access the data.). You can also try to obtain the file from /proc/PID/fd/file_handle

If you have all the single files you need, you can continue with recovering entire directories. In most cases you will notise $ ls /mountpoint is empty. However in some cases you can still $ cd /mountpoint/sub/dir/. From here you might still be able to initiate a copy data.

[edit] FAQ

Some isues you might face when repairing your filesystem:

[edit] memory allocation failed

If you receive this error you do not have enough memory to repair this filesystem. Because of the damage e2fschk might need more bitmaps then usual to check this filesystem.

To resolve this error first try to see if you can add more memory to the system. If this is not an option, consider using zram, zcache or other memory compression techniques. Finally you might wish to add extra swap space.

Please however note that some part of e2fschk use rb_trees. These trees touch many small part of your memory (or swap page). As a result many pages will be paged in, resulting in verry poor performance.

Another possibility is to use scratch_files. To enable this edit /etc/e2fsck.conf.

[edit] Howmuch memory will I need ?

The amount of memory you need can be large. This are some of the numbers seen during checks.

Disk Size Block Size e2fsprogs version Required memory
16TiB 4KiB 1.42.10 30.2GiB+

[edit] Final notes

You might wish to consult the Mailinglists archives for advise and simular issues.

Personal tools