jonny's blog

File System Corruption Problem in Linux Due to Write Back Cache

Write Back Cache is a caching technique in which the modifications to the data in cache are not copied to cache source until completely essential. It is implemented on the hard drives to improve write performance. Devices rely on this method to fix slow performance issues because of slower RPM and seek-time.

With this technique, the hard drive could signal the successful completion of writing process more rapidly than if this had to wait until data was entirely transferred to disk media. Write back caching is available with several microprocessors including Intel.

Though, write back cache is extremely useful technique to improve write performance, but in some cases, like hardware failure and power failure, the write back cache memory does not get flushed out to the actual drive. It may cause corruption of data.

Resizing Linux Volumes Cause File System Corruption and Finally the Data Loss

There are some situations where you may need to resize your Linux hard drive volumes. Volume resizing means increasing/decreasing the size of your hard drive volume. It is generally done to increase the size of a specific volume to store particular data.

Though it is helpful to resize the hard drive volumes but sometimes it may put you in critical situations. When you resize a Linux volume and boot your system it works fine. But if you are using the dual boot system and resize another operating system’s partitions also, you may face critical problems.

After resizing another operating system’s partitions when you boot your system from Linux the system may refuse to boot and you may get the underwritten error message:

“Group XX inode table at XX conflicts with some other fs block. Relocate? Yes

When you select yes, you will get further error message stating:

“Root inode is not a directory. Clear? Yes

Power Loss at Fsck Check in Linux

Dirty shutdowns, minor file system inconsistencies and more, these are the common problems with Linux operating system. So at each boot, the criterion of fsck is meant for preventing the data loss problems with Linux. But contrarily, serious data loss issues have been seen, when the user loses power when fsck is on its way of routine checkup.

In some of the reports, when the user restarts the system, the partitions have been found to be inaccessible. This is the critical situation of data loss as whole of the data appear to come to an end. For the further investigation of the problem, when the user runs fdisk on the partition, similar warning may be seen:

Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): p

Disk /dev/hdb: 203.9 GB, 203928109056 bytes

255 heads, 63 sectors/track, 24792 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System

Command (m for help):