fsck - Error reading block

[jL]

Hello.

I'm new to this group and new to using this firmware.  I have tried searching the group and FAQ for answers for the past 3 days, but no luck.

I have a DNS-323 rev B1.  I flashed Alt F from Dlink 1.08.  I have 2 x 2TB drives in raid0 created by Dlink firmware.  

On first boot of Alt F RC4, the setup wizard took me thru the steps.  My DNS323 then stayed at 100% CPU for fsck /dev/md0.  After about 4 hours, the check finished with error and md0 was mounted as RO.  

I looked in the help pages and this group for solutions.  I then used the "Force Fix" function in Disk > File systems.  That again returned an error and md0 was mounted as RO again.  The error said I had to "Run fsck Manually".  

Back to this group and learned about "fsck -fyC /dev/md0".  So I SSHed into root and after about 3 hours, and a whole bunch of msgs saying the following:

Error reading block XXXXXXXX (Attempt to read block from filesystem resulted in short read) while getting next inode from scan. 

Ignore error<y>? yes 

Force rewrite<y>? yes

This message repeated 10-20 times, then the check did not resume (did not go back to the progress percentage counter).  It just stopped.  I cannot give any command on SSH.  I cannot access the Alt F gui.  The blue power LED on the box was solid blue.  I tried to hold it for three seconds and six seconds for the reboot or shutdown, which did not work.  There was no response from the box after an hour, so I pulled the power to start again.

After restart, instead of waiting another 4 hours for the standard fsck by Alt F (knowing it will return errors), I used the following line to stop the check.

kill $(cat /tmp/check-*.pid)

Starting fsck from SSH resulted in the same errors.

I'm stuck and don't know what I can do next, or what I have done wrong.

Thank you for any help you can provide.

[João Cardoso]

On Monday, August 18, 2014 12:36:00 AM UTC+1, jL wrote:

Hello.

I'm new to this group and new to using this firmware.  I have tried searching the group and FAQ for answers for the past 3 days, but no luck.

I have a DNS-323 rev B1.  I flashed Alt F from Dlink 1.08.  I have 2 x 2TB drives in raid0 created by Dlink firmware.  

On first boot of Alt F RC4, the setup wizard took me thru the steps.  My DNS323 then stayed at 100% CPU for fsck /dev/md0.  After about 4 hours, the check finished with error and md0 was mounted as RO.  

I looked in the help pages and this group for solutions.  I then used the "Force Fix" function in Disk > File systems.  That again returned an error and md0 was mounted as RO again.  The error said I had to "Run fsck Manually".  

Back to this group and learned about "fsck -fyC /dev/md0".  So I SSHed into root and after about 3 hours, and a whole bunch of msgs saying the following:

Error reading block XXXXXXXX (Attempt to read block from filesystem resulted in short read)

That is the key.

You should read the logs (System->Utilities, View Logs) before taking actions as drastic as running 'fsck -y' or running "force fix" from the webUI.

I don't remember the outcome, but if you search for "fsck short read" I think that you will find relevant posts.

In short, "short read" means that an attempt to read past the device (disk/partition or RAID array) end was attempted.

This means that there is an disagreement between the device reported size and the filesystem recorded size of the device. Again, a device can be a disk/partition or RAID; in you case it's the RAID.

Please search the forum again

 

while getting next inode from scan. 

Ignore error<y>? yes 

Force rewrite<y>? yes

This message repeated 10-20 times, then the check did not resume (did not go back to the progress percentage counter).  It just stopped.  I cannot give any command on SSH.  I cannot access the Alt F gui.  The blue power LED on the box was solid blue.  I tried to hold it for three seconds and six seconds for the reboot or shutdown, which did not work.  There was no response from the box after an hour, so I pulled the power to start again.

The system was hung.

 

After restart, instead of waiting another 4 hours for the standard fsck by Alt F (knowing it will return errors), I used the following line to stop the check.

kill $(cat /tmp/check-*.pid)

Starting fsck from SSH resulted in the same errors.

I'm stuck and don't know what I can do next, or what I have done wrong.

You probably have done nothing wrong. The issue is that it seems that the D-Link fw sometimes creates filesystems on RAID incorrectly. If I remember correctly, there is a small size disagreement

And with D-Link "policy" of not running fsck, that issue always remains covered until users switch to Alt-F (or attach the disk to any linux system that does a proper fsck)

[jL]

Thank you for your response.

this is the the systemerror.log had to say:

Unable to automatically fix md0, mounting Read Only: fsck 1.41.14 (22-Dec-2010)
/dev/md0 contains a file system with errors, check forced.
Error reading block 766607407 (Attempt to read block from filesystem resulted in short read) while getting next inode from scan.  

/dev/md0: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
	(i.e., without -a or -p options)

I tried to search for "fsck short read" in this forum, and the closest result I found was regarding a short read while expanding or enlarging the file system, which is not what i'm doing.  Is this the solution i should try?

In the systemlog.log (attached) I see a lot of "Buffer I/O error".  Is this part of the problem?

thank you again.

[João Cardoso]

On Monday, August 18, 2014 6:02:04 AM UTC+1, jL wrote:

Thank you for your response.

this is the the systemerror.log had to say:

Unable to automatically fix md0, mounting Read Only: fsck 1.41.14 (22-Dec-2010)
/dev/md0 contains a file system with errors, check forced.
Error reading block 766607407 (Attempt to read block from filesystem resulted in short read) while getting next inode from scan.  

/dev/md0: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
	(i.e., without -a or -p options)

I tried to search for "fsck short read" in this forum, and the closest result I found was regarding a short read while expanding or enlarging the file system,

Yes, that is the solution, shrinking the filesystem a small amount so that it fits the enclosing device size. *Not* the Shrink option on the Filesytem Maintenance webUI.

That said, I see other kind of errors in your log, e.g:

ata1.00: exception Emask 0x0 SAct 0x3 SErr 0x0 action 0x6

Aug 17 20:06:18 dns323 user.err kernel: ata1.00: edma_err_cause=00000084 pp_flags=00000003, dev error, EDMA self-disable

Aug 17 20:06:18 dns323 user.err kernel: ata1.00: cmd 60/00:00:02:e7:b5/01:00:05:00:00/40 tag 0 ncq 131072 in

Aug 17 20:06:18 dns323 user.err kernel:          res 41/40:00:e8:e7:b5/00:00:05:00:00/40 Emask 0x409 (media error) <F>

Aug 17 20:06:18 dns323 user.err kernel: ata1.00: cmd 60/40:08:12:de:b7/00:00:05:00:00/40 tag 1 ncq 32768 in

Aug 17 20:06:18 dns323 user.err kernel:          res 41/40:04:02:e7:b5/40:00:05:00:00/40 Emask 0x9 (media error)

Aug 17 20:06:18 dns323 user.info kernel: ata1: hard resetting link

and others. I don't remember if the two errors (the short read and the above) are related, but I don't think they are. Check the logs in the other post.

You can also do a SMART check on the drives, to see if it/they are failling (Disk->Utilities)

In any case, the filesystems are mounted RO so that you can make a backup of your data.

 

which is not what i'm doing.  Is this the solution i should try?

As I remember, the 'resize2fs' solved the short read issue in the *other* post. The issue was at the time diagnosed as the filesystem thinking  the disk being bigger than it actually is.

That post explains it all, just follow it and adapt to your case, to see if the same conclusion can be taken for you.

[jL]

Hello Joao,

Sorry to bother you with problems again

I tried the "resize2fs", which gave met he following result:

Can't read next inode while trying to resize /dev/md0

Please run 'e2fsck -fy /dev/md0' to fix the filesystem

after the aborted resize operation.

So I ran "e2fsck -fy /dev/md0".... and after an 3 or so hours, I got a whole bunch of errors and the system crashed/hung.

[root@dns323]# e2fsck -fy /dev/md0

e2fsck 1.41.14 (22-Dec-2010)

Pass 1: Checking inodes, blocks, and sizes

Error reading block 766607407 (Attempt to read block from filesystem resulted in short read) while getting next inode from scan.  Ignore error? yes

Force rewrite? yes

Error reading block XXXXXXXXX (Attempt to read block from filesystem resulted in short read) while getting next inode from scan.  Ignore error? yes

Force rewrite? yes

I tried to understand the errors, and the XXXXXXXXX in the error were actually consecutive blocks from 766607424 to 766607466.  After that last error, the system crashed.

The 2x2TB drives in Raid0 are approx. 3/4 full.  and 766 millionth block is approximately 3/4 of 975million blocks (size of file system.  

Is it safe to assume the short read is caused by the free space available on the disks?

I really don't know what I can do next to fix this problem, because I get the same results everytime.

[João Cardoso]

On Tuesday, August 19, 2014 4:55:39 AM UTC+1, jL wrote:

Hello Joao,

Sorry to bother you with problems again

I tried the "resize2fs", which gave met he following result:

This command will not work in your situation without specific options. As is, it will do the same as the "Shrink" option in the Filesystem Maintenence webUI.

 

Can't read next inode while trying to resize /dev/md0

Please run 'e2fsck -fy /dev/md0' to fix the filesystem

after the aborted resize operation.

So I ran "e2fsck -fy /dev/md0".... and after an 3 or so hours, I got a whole bunch of errors and the system crashed/hung.

That is just the same that is done by the "Force Fix" option in the "Filesystem Maintenance" webUI. It will also not solve your issue.

[root@dns323]# e2fsck -fy /dev/md0

e2fsck 1.41.14 (22-Dec-2010)

Pass 1: Checking inodes, blocks, and sizes

Error reading block 766607407 (Attempt to read block from filesystem resulted in short read) while getting next inode from scan.  Ignore error? yes

Force rewrite? yes

Error reading block XXXXXXXXX (Attempt to read block from filesystem resulted in short read) while getting next inode from scan.  Ignore error? yes

Force rewrite? yes

I tried to understand the errors, and the XXXXXXXXX in the error were actually consecutive blocks from 766607424 to 766607466.

This probably means that there is a spot in the disk surface that is defective. Read this, near the end http://ubuntuforums.org/showthread.php?t=1567879

But first:

0-Can you do a backup of your data first?

1-Have you run the SMART tests (Disk->Utilities. Health, at least get the status or do a short test, post the results)

2-Have you unmounted the filesystem before doing any of the above resize/fsck?

The "resize" applies to a different situation, which can also lead to s "short read" message, see the superblock or the partition table is likely to be corrupt

but only with the command outputs and analysis done in that thread it is possible to determine that.

Can't apply a cure without having a diagnostic first.

Diagnose first if the problem is on the disk hardware/surface using the SMART tests and logs.

 

 After that last error, the system crashed.

The 2x2TB drives in Raid0

RAID0? not RAID1? Yes, just checked your log, it's RAID0, I missed that first time.

Then you must have a backup, because you know that RAID0 is unreliable -- one drive fails, all data is gone.

 

are approx. 3/4 full.  and 766 millionth block is approximately 3/4 of 975million blocks (size of file system.  

Is it safe to assume the short read is caused by the free space available on the disks?

No.

You mean "assume that the short read *occurs* in the the free space"? can't say, disk space isn't used sequentially, it depends on the previous disk usage and file creation/deletion/size patterns.

 

I really don't know what I can do next to fix this problem, because I get the same results everytime.

Do the above 0,1 first

[ccinfo...@gmail.com]

hi team,

i am new user the same problem i am facing error reading block,i am using centos 6.4 for asterisk but now this issue i was facing please help me because there are many call recording data in that folder so please help as