4

I had a I/O error on an external hard drive partition sdb4 (its usual mountpoint being /run/media/yan/data).

The partition was non responsive, couldn't be accessed and refused to unmount. I did not know what to do but unplug the disk and replug it. After that I had error on its fs, so I ran fsck:

sudo e2fsck /dev/sdb4 -y -v

It was asking for a lot of fixes (thousands) but since data is non-critical on that disk, I ran it with -y.

data contains a file system with errors, check forced.

Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
# Fixed invalid inode numbers, incorrect filetypes, cleared links, deleted/unused inodes
Pass 3: Checking directory connectivity
# Connected unconnected directory inodes to /lost+found
Pass 4: Checking reference counts
#Fix inodes ref count, connected unattached inode to /lost+found
Pass 5: Checking group summary information
# Fix block bitmap differences, blocks count wrong for group
# Fix inode bitmap differences, directories count wrong for group, free inodes count wrong for group

data: ***** FILE SYSTEM WAS MODIFIED *****

       72955 inodes used (0.14%, out of 51200000)
        2390 non-contiguous files (3.3%)
          17 non-contiguous directories (0.0%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 72264/636/1
   186984621 blocks used (91.30%, out of 204800000)
           0 bad blocks
          34 large files

       70447 regular files
        2453 directories
           0 character device files
           0 block device files
           0 fifos
  4294966642 links
          46 symbolic links (46 fast symbolic links)
           0 sockets
------------
   71063 files

So if I understand correctly, fsck managed to salvage 70k files, so most of the files since I had like 75-80k files on that disk. The problem is that only 20k files appear in '/run/media/yan/data/lost+found', and only 24k on the entire partition.

[yan@machine ~]$ find /run/media/yan/data/lost+found | wc -l
19786
[yan@machine ~]$ find /run/media/yan/data | wc -l
23691

I reran fsck but he tells me that the partition is clear (and has 74k files ?)

[yan@machine ~]$ sudo fsck /dev/sdb4
fsck from util-linux 2.28
e2fsck 1.42.13 (17-May-2015)
data: clean, 74200/51200000 files, 186685980/204800000 blocks[/cpp]

I also have very different disk usage according to df and du (I know there should be a difference, but here it seems too big to be normal):

[yan@machine ~]$ df -h /run/media/yan/data
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb4       769G  700G   31G  96% /run/media/yan/data

[yan@machine ~]$ du -sh /run/media/yan/data
586G    /run/media/yan/data

I'm guessing there is still recovered data that I can't access. My questions are :

1) Is it possible for recovered files by fsck to not be place in lost+found ? In that case, where are they ?

2) Is there any way to get back those missing files ?

3) If not, how do I free this space ?

EDIT:

I tried a more recent version of e2fsck on sourcejedi's recommandation:

[yan@machine build]$ sudo ./e2fsck/e2fsck -f /dev/sdb4
e2fsck 1.43.3 (04-Sep-2016)
Pass 1: Checking inodes, blocks, and sizes
Inode 40501578 extent tree (at level 2) could be narrower.  Fix<y>? yes

Pass 1E: Optimizing extent trees
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

data: ***** FILE SYSTEM WAS MODIFIED *****
data: 74200/51200000 files (3.2% non-contiguous), 186685964/204800000 blocks

It did not do much, lost+found still has the same file count and size.

1 Answer 1

0

i also notice link count is very suspicious (nearly 2^32).

you can try more recent e2fsck, and/or report a bug. this is certainly a bug.

scanning the device/partition with photorec might restore more files, where the format is supported and they are contiguous. since your FS is quite full, many files are not contiguous. photorec does not recover file names or directories. (e.g. if they're mp3's, you can use something like picard to apply filenames from the mp3 metadata aka ID3 tags). note photorec requires free space on another filesystem, to recover all the files to.

1
  • e2fsck was 1.42.13, the latest version disponible in repos. I've build the latest version 1.43.3 and tried it too (see my edit), but to no avail. Apparently, I have few non-contiguous files (which is in fact not really surprising, I almost never erased files on that fs, I'll try photorec once I received my new HDD). I might also try to open a ticket on whatever code repository e2fsck is using. Still, thanks for your answer.
    – Yann
    Nov 6, 2016 at 16:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .