Linux – Unable to resolve data corruption warning with fsck

corruptionfat32fscklinuxpartition

In order to create a contiguous space for my file system to grow, I created a new EFI System partition at sda1 so that I can migrate it from the current partition at sda5. The move itself has been successful except for a warning which says:

kernel: FAT-fs (sda1): Volume was not properly unmounted. Some data
may be corrupt. Please run fsck.

I didn't notice the warning which has been there for two days when I first created the EFI partition. I unmounted the file system and performed a file system check as follows:

# umount /dev/sda1
# fsck -V /dev/sda1
fsck from util-linux 2.24
[/sbin/fsck.vfat (1) -- /boot/efi] fsck.vfat /dev/sda1 
fsck.fat 3.0.24 (2013-11-23)
0x25: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
1) Remove dirty bit
2) No action
? 1
Leaving filesystem unchanged.
/dev/sda1: 14 files, 2435/51145 clusters

I thought removing the dirty bit would resolve this. But it didn't. What should actually be done?

Best Answer

This is stupid. I find myself answering my own question again. It says,

Leaving filesystem unchanged.

suggesting that nothing is changed. This actually mean that typing 1 followed by pressing enter inside the fsck prompt did not work. Anyway, the following does work:

# fsck.vfat -v -a -w /dev/sda1

The above command automatically write changes to disk. It would be great if anyone can tell me whether this is a bug in fsck or it is due to something else.

Related Solutions

Linux – Any way to recover ext4 filesystems from a deleted LVM logical volume

Every time you perform an operation with LVM, by default, the previous metadata is archived in /etc/lvm/archive. You can use vgcfgrestore to restore it, or grab the extends by hand (harder, but lvcreate(8) should cover it).

Edit:

And to make it as easy as possible, I should add that you can find the last backup before your destructive operation by looking at descriptions:

# grep description /etc/lvm/archive/vg01_*
/etc/lvm/archive/vg01_00001.vg:description = "Created before executing 'lvremove -f /dev/vg01/foo'"
/etc/lvm/archive/vg01_00002.vg:description = "Created before executing 'lvremove -f /dev/vg01/bar'"
/etc/lvm/archive/vg01_00003.vg:description = "Created before executing 'lvremove -f /dev/vg01/baz'"

Edit:

The normal allocation policy (default one) will allocate a stripe from the first free PE when there is enough room to do so. If you want to confirm where the LV was allocated, you can look in the archive files, those are perfectly readable by humans.

Linux: Force fsck of a read-only mounted filesystem

You can fsck a read-only filesystem, because mounting read-only doesn't mark it as "dirty" the way read-write mounting does. There are no changes sitting in a write cache that might be only partially flushed to disk, so all the on-disk structures are consistent and safe for fsck to modify.

However, if fsck makes any changes, the kernel's filesystem driver might become confused, because things that it expected to remain constant have instead changed out from under it. This won't affect the integrity of the filesystem itself (since the driver isn't writing to it), but it may make the running system unstable. To avoid that, you should reboot if fsck made any changes to your filesystem.

Best Answer

Related Solutions

Linux – Any way to recover ext4 filesystems from a deleted LVM logical volume

Linux: Force fsck of a read-only mounted filesystem

Related Topic