linux-ext4 - filesystem unrepairable after resizing from 16TB to 20TB

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Wed, 19 Mar 2014 11:34:04 +0100
From:	Jens Pranaitis <pranaitis@...l.hhu.de>
To:	linux-ext4@...r.kernel.org
Subject: filesystem unrepairable after resizing from 16TB to 20TB

Dear all,

after resizing a 64bit ext4 filesystem from 16TB to 20TB, which 
completed without errors, I started a rsync of ~3TB, about 30min into 
the copy the following kernel messages started to pop up:

Mar 17 12:03:31 s_local@...kup1/backup1 kernel: [2081501.742613] EXT4-fs 
(dm-2): mounted filesystem with ordered data mode. Opts: acl,user_xattr
Mar 17 12:37:10 s_local@...kup1/backup1 kernel: [2083523.489419] EXT4-fs 
error (device dm-2): ext4_mb_generate_buddy:755: group 1, 30820 clusters 
in bitmap, 30207 in gd
[...]

I attached the full kernel log from the day of the resize.

There are a lot of broken files and when trying to fix them with e2fsck 
the program exits:

Inode 2195807 has an invalid extent node (blk 35192760, lblk 0) 

Clear? yes

e2fsck: e2fsck_read_bitmaps: illegal bitmap block(s) for /dev/vg-data/backup

/dev/vg-data/backup: ***** FILE SYSTEM WAS MODIFIED *****
e2fsck: aborted

You can find the output of e2fsck -n /dev/vg-data/backup at
http://user.phil.hhu.de/~pranaitis/e2fsck.log.xz
the uncompressed log size is 357MB so I thought I'd rather not send it 
via this list.

The kernel version is 3.11-0.bpo.2-amd64 from Debian backports. The 
e2fsprogs version is vanilla 1.42.9.

The machine itself is a VM created with VMWare ESXi 5.5.0 using Thick 
Provisioned disks.

I don't have any hope of salvaging the filesystem, but is there anything 
I can do to help in preventing such issues in the future?

Kind regards,

Jens Pranaitis
-- 
IKM-Serviceteam der Philosophischen Fakultät
HHU Düsseldorf
Gebäude 23.21, Ebene 04, Raum 88
Tel.: 0211/81-13077

View attachment "kernel-ext4-mar17.log" of type "text/x-log" (6014 bytes)