R
R
ReBlock2011-03-18 10:36:33
linux
ReBlock, 2011-03-18 10:36:33

Flew the file system in linux?

Today I came to work and noticed that the server is down. After the reboot, I saw in the console an unsuccessful automatic fsck check and a suggestion to deal with this issue manually after entering the root password. In general, some blocks cannot be read, when checking, it asks for permission to force rewrite

/dev/VolGroup00/LogVol00 contains a file system with errors, check forced.<br/>
Pass 1: Checking inodes, blocks, and sizes<br/>
Error reading block 655367 (Attempt to read block from filesystem resulted in short read) while doing inode scan. Ignore error? yes<br/>
<br/>
Force rewrite? yes<br/>
<br/>
Error reading block 655368 (Attempt to read block from filesystem resulted in short read) while doing inode scan. Ignore error? yes<br/>
<br/>
Force rewrite? yes<br/>
<br/>
Error reading block 655369 (Attempt to read block from filesystem resulted in short read) while doing inode scan. Ignore error? yes<br/>
<br/>
Force rewrite? yes

Tell me what to do in order to restore working capacity as safely as possible? How can I find out how many such problem areas are on the hdd? Is it risky to run fskk -y /dev/VolGroup00/LogVol00?

Answer the question

In order to leave comments, you need to log in

3 answer(s)
A
admin4eg, 2011-03-18
@admin4eg

Recently, my mirror raid also gave up life, one disk died, the second one began to fail almost “at once”.
after the rebuild, FS flew away and for a long time fsck with the -c switch worked for more than a day.
I didn’t lose the data, but the directory tree flew far away ... I got a bunch of scattered branches of the former tree in the /lost+found/ directory I
was puzzled by hot backups, so that later for a week I wouldn’t collect everything in a heap, what was where ...
iron, something that had long been lying in the back of history , so we needed a sata controller + a raid for at least 4 ports + a pack of new disks for 1.5, the
beloved ubuntu server did not want to work with a cunning soft-trade controller during installation.
merged debian and it created fakeRAID during installation, after which munin was installed and I found that munin got hooked and shows smart of all screws ...
further analysis revealed that all 1.5TB screws in the organization decided to go to another world, this is according to smart, if I monitored these indicators a little more often than never, then perhaps my life would be a little easier.

W
webster, 2011-03-18
@webster

> fcsk -y /dev/VolGroup00/LogVol00
try ...
And what is the FS? 3.4?

E
ENargit, 2011-03-18
@ENargit

The testdisk utility helped me several times even in cases where fsck failed. I wish that it did not come to this, but if by chance - keep in mind.
Problem areas on hdd - easy if the disk supports SMART technology

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question