Arch Linux

noalwin

Member

From: Spain

Registered: 2007-06-08

Posts: 115

Data corruption after resizing partitions.

Hello.

Today I wanted to resize some partitions to redistribute better the available space. The partitions were ext4 and I used gparted live 0.4.6

Gparted seemed to make all the chages without errors, the system booted fine. When it reached the login manager (KDM) I switched to a virtual terminal and restarted forcing a fsck (shutdown -F) When the system booted, it found errors on my main partition but seemed to correct them. The other partitions didn't reported errors.

The thing is, that when I went to use the system, I found that /usr/bin/psi had been overwritten with zeroes.

The rest of the system seems to work fine (update: many other files seems corrupted), but I would want to be sure that there are no more corrupt data. Any idea on how to be sure about it? Do you have any advice for me?

Edit:

I shrinked my main partition and a test partition, and enlarged the others.
I have taken a look to the e2fsprogs changelog (the last one is 1.41.9 and gparted comes with 1.41.3) and found several fixes about resizing:

1.41.8
Fix potential filesystem corruptions caused by using resize2fs to shrinking ext4 filesystems with extents enabled. (Addresses Red Hat Bug: #510379)
1.41.7
Fix a bug in libext2fs which can cause e2fsck and resize2fs to write uninitalized data into the portion of the inode beyond the first 128 bytes when operating on inodes mapped via extents; potentially corrupting filesystems.
1.41.6
Avoid corrupting the filesystem if there is an attempt to shrink a filesystem using resize2fs smaller than posible by making ext2fs_set_bmap() more careful not to delete the old block until the new block can be inserted. In addition, fix a bug in how the minimum size of the filesystem (plus a safety margin) is calculated, and modify resize2fs to refuse to shrink the filesystem below that minimum size without the force flag.
1.41.5
Fix a number of filesystem corruption bugs in resize2fs when growing or shrinking ext4 filesystems off-line (i.e., when the ext4 filesystem is not mounted).
1.41.4
Fix resize2fs for ext4 filesystems. Some blocks that that need moving when shrinking filesystems with uninit_bg feature would not be moved. In addition, blocks and inode table blocks were not being correctly freed when shrinking filesystems with the flex_bg feable, which caused resize2fs -M to fail. Finally, when blocks are moved, make sure the uninitialized flag in extents is preserved.

Edit2:
There are more corruptions: /usr/lib/chromium/chromium and /usr/lib/libgpm.so.2 also has been zeroed

I suspect of all the files listed on: http://pastebin.com/d11e35dfe

Edit3:
I have done backups of most of my user data with rdiff backup. I guess that I could use that to look what files may have changed.

Edit4:
I installed a minimal system on the test partition and mounted the others as read only.

I have seen that zeroed files use zero disk blocks but the size reported is not zero. So I used a script to compare the values and found that 12315 files had been zeroed.

The next step will be to make a diff between the data and the backups to doublecheck that data.
Next I will format the system partition and reinstall the system. I will look if there is a way to reinstall all the packages from a sane /var/lib/pacman (it was on a reiserfs partition, and I also had backups)

After that I will copy the data of the other partitions, format them and copy them back.

Things learned:
Always have backups.
If you are going to make something risky, do a backup just before that.
If you are going to change partitions, always be sure to check if the tools used are on their last version (if not, at least check the changelog)

Last edited by noalwin (2010-01-21 14:33:54)