Tag Archives: ext4

How to run the dry filesystem check on ext4 and xfs ?

In this article I am going to show how to run the experimental file system  check on the filesystem like ext3,ext4 and XFS.
In these examples I have shown the usage for ext4 and XFS. Procedure for ext3 is same like ext4.

Step 1 : I have one file system mounted on /mnt3. I want to run the file system check on it. But due to fear of losing the data. I want to run the experimental check first before running it on original filesystem.

[root@Node-1-65 ~]# df -h
Filesystem                      Size  Used Avail Use% Mounted on
/dev/mapper/vg_node165-lv_root   11G  2.1G  7.6G  22% /
tmpfs                           489M     0  489M   0% /dev/shm
/dev/vda1                       485M   34M  426M   8% /boot
/dev/vdb2                        98M  5.6M   87M   6% /mnt2
/dev/vdb3                        98M  5.6M   87M   6% /mnt3

Step 2 : I have unmounted the file system and then created the e2image for the file system.

The e2image creates the image file as a sparse file, which will make the file size smaller than the total filesystem size.

[root@Node-1-65 ~]# umount /mnt3
[root@Node-1-65 ~]# e2image -r /dev/vdb3 – | bzip2 > /tmp/mnt3.image.e2i.gz
e2image 1.41.12 (17-May-2010)

While compressing the image file, the compression tool used should be aware of sparse files, to avoid it to create a non-sparsed image during file compression. Alternatively it’s possible to use ‘e2image’ command with option ‘-Q’, instead ‘-r’. It will create a QCOW2 image file instead of a normal, or raw image file. A QCOW2 image contains all the information the raw image does, however unlike the raw image it is not sparse. The QCOW2 image minimize the amount of disk space by storing data in special format with pack data closely together, hence avoiding holes while still minimizing size.

Step 3 : The bzip2 tool does not recognise sparse files and will compresses the empty regions of the file as normal data but the compression rate will be very high. When bunzip2 uncompresses the file it will allocate space for the empty data and the resultant image file will be fully allocated.

In this case it is necessary to filter out the empty data with a command like:

[root@Node-1-65 ~]# bzcat /tmp/mnt3.image.e2i.gz | cp –sparse=always /dev/stdin image.e2i

We can verify that file is sparse using below command. We can see the difference between actual size(316KB) and the reserverd size (101MB) approx of filesytsem size.

[root@Node-1-65 ~]# ls -lsh /root/image.e2i
316K -rw——- 1 root root 101M Jan 12 21:35 /root/image.e2i

Step 4 : Now we can loopback that image. We can see that its showing the size of actual file system.

[root@Node-1-65 ~]# mount -o loop /root/image.e2i /mnt
[root@Node-1-65 ~]# df -h /mnt
Filesystem       Size  Used Avail Use% Mounted on
/root/image.e2i   98M  5.6M   87M   6% /mnt

Step 5 : Running file system check on mounted image file.

[root@Node-1-65 ~]# e2fsck -vvv /root/image.e2i
e2fsck 1.41.12 (17-May-2010)
/root/image.e2i is mounted.

WARNING!!!  The filesystem is mounted.   If you continue you ***WILL***
cause ***SEVERE*** filesystem damage.

Do you really want to continue (y/n)? yes

/root/image.e2i: recovering journal
/root/image.e2i: clean, 11/25792 files, 8909/102816 blocks

We can do the same thing for xfs file system as well procedure is bit different.

Step 1 : I have one mounted xfs file system of 1GB. I want to run the experimental or dry filesystem check on this.

[root@vikrant ~]# df -h /new_xfs/
Filesystem                        Size  Used Avail Use% Mounted on
/dev/mapper/vg_storage-xfs_check 1014M   33M  982M   4% /new_xfs

Step 2 : Unmount the filesystem and make the image of metadump of the filesystem.

[root@vikrant ~]# umount /new_xfs/
[root@vikrant ~]# xfs_metadump /dev/mapper/vg_storage-xfs_check /tmp/xfsimage1.img

Step 3 : Create sparse file of 1GB. As my original filesystem is of 1GB.

[root@vikrant ~]# truncate -s 1G /root/xfsimage.img

Verify the same with below command.

[root@vikrant ~]# ls -lsh /root/xfsimage.img
11M -rw-r–r– 1 root root 1.0G Jan 13 08:16 /root/xfsimage.img

Step 4 : I am restoring the metadata dump to sparse file created in previous step.

[root@vikrant ~]# xfs_mdrestore -g /tmp/xfsimage1.img /root/xfsimage.img
0 MB read

Step 5 : Now we can run the filesystem check on it.

[root@vikrant ~]# xfs_repair -f /root/xfsimage.img
Phase 1 – find and verify superblock…
Phase 2 – using internal log
– zero log…
– scan filesystem freespace and inode maps…
– found root inode chunk
Phase 3 – for each AG…
– scan and clear agi unlinked lists…
– process known inodes and perform inode discovery…
– agno = 0
– agno = 1
– agno = 2
– agno = 3
– process newly discovered inodes…
Phase 4 – check for duplicate blocks…
– setting up duplicate extent list…
– check for inodes claiming duplicate blocks…
– agno = 0
– agno = 1
– agno = 2
– agno = 3
Phase 5 – rebuild AG headers and trees…
– reset superblock…
Phase 6 – check inode connectivity…
– resetting contents of realtime bitmap and summary inodes
– traversing filesystem …
– traversal finished …
– moving disconnected inodes to lost+found …
Phase 7 – verify and correct link counts…

Advertisements

Analogy between ext4 and xfs commands

Property Name

Ext4

Xfs

Creating New FS

mkfs.ext4

mkfs.xfs

Check and repair the FS

E2fsck

xfs_repair

Resize the FS

Resize2fs

xfs_growfs

Extract and restore meta data dump

E2image

xfs_metadump,xfs_mdrestore

Read the SuperBlock information

Dump2fs

xfs_info

Change tuneable parameters

Tune2fs

xfs_admin

File System Debugging

Debugfs

xfs_db

Defragment the FS

xfs_fsr

Backup and restore the FS

Dump/restore

Xfsdump/xfsrestore

Manage Quota

Quota/setquota

xfs_quota

File Mapping

Filefrag

xfs_bmap

How to Fix issue with File system Superblock in Red Hat Linux

Sometimes the file system superblock is getting corrupted. In worst case scenario we are also not able to run the file system check. By default file system check will be performed the on the superblock located at 0.
But nothing to worry as we know the superblock is having multiple copies saved at different locations in a file system. We can use those copies to to run the e2fsck on file system or to mount the file system.

Now the question arises

  • How would we come to know about the location of copies of superblock?
  • How can we run the file system check using another copy of superblock?
  • How can we mount the file system using another copy of superblock?

In this article I am going to address all these questions.

I have one file system of 19G on which I am going to perform all the actions.

Question 1 : How would we come to know about the location of copies of superblock?

Answer 1 : dumpe2fs and mke2fs commands can be used to know about superblock.

dumpe2fs : This command can be used on mounted file system as well means the file systems which are working absolutely fine.

After running this command you will get to know each and every term associated with file system from that platheora of information you can capture only superblock information.

[root@node1 ~]# dumpe2fs /dev/mapper/VolGroup01-VolLV01 | grep -i superblock
dumpe2fs 1.41.12 (17-May-2010)
Primary superblock at 0, Group descriptors at 1-2
Backup superblock at 32768, Group descriptors at 32769-32770
Backup superblock at 98304, Group descriptors at 98305-98306
Backup superblock at 163840, Group descriptors at 163841-163842
Backup superblock at 229376, Group descriptors at 229377-229378
Backup superblock at 294912, Group descriptors at 294913-294914
Backup superblock at 819200, Group descriptors at 819201-819202
Backup superblock at 884736, Group descriptors at 884737-884738
Backup superblock at 1605632, Group descriptors at 1605633-1605634
Backup superblock at 2654208, Group descriptors at 2654209-2654210
Backup superblock at 4096000, Group descriptors at 4096001-4096002

mke2fs : This command should be run on unmounted file system. NOTE : Don’t run this command without -n option.

[root@node1 ~]# mke2fs -n /dev/mapper/VolGroup01-VolLV01
mke2fs 1.41.12 (17-May-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
1245184 inodes, 4980736 blocks
249036 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
152 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000

So first most important question is answered.

Question 2 : How can we run the file system check using another copy of superblock?

Answer 2 : As we were not able to run the file system check on superblock at 0 location. Hence we proceed with file system check on superblock at 32768(Value taken from Step1 output).

Able to run the file system check on copy of superblock.

[root@node1 ~]# e2fsck -b 32768 /dev/mapper/VolGroup01-VolLV01
e2fsck 1.41.12 (17-May-2010)
One or more block group descriptor checksums are invalid. Fix<y>? yes

Group descriptor 0 checksum is invalid. FIXED.
Group descriptor 1 checksum is invalid. FIXED.
Group descriptor 2 checksum is invalid. FIXED.
Group descriptor 3 checksum is invalid. FIXED.
Group descriptor 4 checksum is invalid. FIXED.

Question 3 : How can we mount the file system using another copy of superblock?

Answer 3 : As we are not able to mount the file system using default superblock which starts at 0. We will try to mount the file system copy of superblock.

[root@node1 ~]# mount -o sb=98304 /dev/mapper/VolGroup01-VolLV01 /var/crash1

Tip : One useful command to determine when the file system is created and last mount time”

[root@node1 ~]# dumpe2fs -h /dev/mapper/vg_node1-lv_root | grep -E “Filesystem created|Last mount time”
dumpe2fs 1.41.12 (17-May-2010)
Filesystem created: Fri May 9 15:05:30 2014
Last mount time: Thu Jun 26 22:37:06 2014