File Corruption

File Corruption

[jeff leads]

Ok, I'm running RedHat 7.1, gcc 2.96-85, kernel
2.4.9-21 (redhat's version) and ReiserFSProgs 3.6.3 (
just upgraded from 3.x0j-1).

I'm starting to get file corruption here and there. 
My next question is, where do I go from here?  What
can I do to rectify this issue?  Do I run a rebuild at
this point?  What caused this?  

I know it's a lot of questions.  Just looking for a
point in the right direction. 

I've been seeing some of these messages in the message
logs, It started happening about 2 weeks ago after
about 8 months of flawless service.

Sep 30 14:03:11 goku kernel: is_tree_node: node level
64680 does not match to the expected one 1
Sep 30 14:03:11 goku kernel: vs-5150: search_by_key:
invalid format found in block 47718. Fsck?
Sep 30 14:03:11 goku kernel: is_tree_node: node level
64680 does not match to the expected one 1
Sep 30 14:03:11 goku kernel: vs-5150: search_by_key:
invalid format found in block 47718. Fsck?
Sep 30 14:03:11 goku kernel: vs-5657:
reiserfs_do_truncate: i/o failure occurred trying to
truncate [116139 106872 0xfffffffffffffff DIRECT]



When I ran a reiserfsck --check I got the output
below.


[root@goku /root]# reiserfsck /dev/ida/c0d0p5

<-------------reiserfsck, 2001------------->
reiserfsprogs 3.x.0j

Will read-only check consistency of the partition
Will put log info to 'stderr'
Do you want to run this program?[N/Yes] (note need to
type Yes):Yes
Analyzing journal..last flushed trans 9936623,
mount_id 120, will replay from 9936624 up to
9936665:Yes?Mount_id 120, transaction 9936624, desc
block 1395, commit block 1404: ( 47578 47649 7733248
16 47715 46480 54961 28273)
Mount_id 120, transaction 9936625, desc block 1405,
commit block 1413: ( 47578 47649 7733248 16 47715
46480 14926)
Mount_id 120, transaction 9936626, desc block 1414,
commit block 1421: ( 47649 47578 16 7733248 47715
46480)
Mount_id 120, transaction 9936627, desc block 1422,
commit block 1429: ( 47649 47578 7733248 16 47715
46480)
Mount_id 120, transaction 9936628, desc block 1430,
commit block 1441: ( 47649 7733248 16 47715 46480
47578 32768 47716 33073 25296)
Mount_id 120, transaction 9936629, desc block 1442,
commit block 1446: ( 47649 47578 16)
Mount_id 120, transaction 9936630, desc block 1447,
commit block 1454: ( 47649 47578 7733248 16 47715
46480)
Mount_id 120, transaction 9936631, desc block 1455,
commit block 1502: ( 47649 47578 7733248 16 47715
46480 47716 45332 56044 65112 31402 36988 10174 10165
14938 9536 83232 33731 10534 8330 8342 27677 27674
8365 18184 27703 27999 14952 12599 18186 18376 9364
9408 9431 33241 45073 43361 28273 12583 27994 34308
9533 67489 67491 67498 1015808)
Mount_id 120, transaction 9936632, desc block 1503,
commit block 1512: ( 47578 47649 7733248 16 47716
46480 54961 28273)
Mount_id 120, transaction 9936633, desc block 1513,
commit block 1537: ( 47649 47578 7733248 16 47716
46480 36988 10174 10165 14938 9536 83232 33731 10534
8330 8342 27677 27674 8365 18184 27703 27999 10107)
Mount_id 120, transaction 9936634, desc block 1538,
commit block 1557: ( 47578 47649 7733248 16 47716
46480 14952 9431 14938 10174 33241 45073 43361 27994
32768 47717 33073 14926)
Mount_id 120, transaction 9936635, desc block 1558,
commit block 1574: ( 47649 47578 7733248 16 47716
46480 10161 10174 10165 14938 83232 33731 10534 27674
67567)
Mount_id 120, transaction 9936636, desc block 1575,
commit block 1601: ( 39068 47578 47649 7733248 16
47716 46480 36988 10174 10165 14938 9536 83232 33731
10534 8330 8342 27677 27674 8365 18184 27703 27999
10107 47717)
Mount_id 120, transaction 9936637, desc block 1602,
commit block 1609: ( 47649 47578 16 7733248 47717
46480)
Mount_id 120, transaction 9936638, desc block 1610,
commit block 1617: ( 47649 7733248 16 47717 46480
47578)
Mount_id 120, transaction 9936639, desc block 1618,
commit block 1622: ( 47649 47578 16)
Mount_id 120, transaction 9936640, desc block 1623,
commit block 1655: ( 47578 47649 7733248 16 47717
46480 55738 42257 73886 55877 43960 55671 36869 10107
10534 27999 12583 36867 9545 10174 10165 14938 12608
83232 33731 9737 1015808 36829 33073 32768 36870)
Mount_id 120, transaction 9936641, desc block 1656,
commit block 1667: ( 47649 47578 7733248 16 47717
46480 54961 28273 24159 48831)
Mount_id 120, transaction 9936642, desc block 1668,
commit block 1677: ( 45073 48831 47649 47578 7733248
16 47717 46480)
Mount_id 120, transaction 9936643, desc block 1678,
commit block 1687: ( 47649 47578 7733248 16 47717
46480 59424 40789)
Mount_id 120, transaction 9936644, desc block 1688,
commit block 1695: ( 47649 7733248 16 47717 46480
47578)
Mount_id 120, transaction 9936645, desc block 1696,
commit block 1700: ( 47578 47649 16)
Mount_id 120, transaction 9936646, desc block 1701,
commit block 1737: ( 47649 47578 7733248 16 47717
46480 55738 42257 73886 55877 43960 55671 36869 10107
10534 27999 12583 32768 47718 33073 36867 9545 10174
10165 14938 12608 83232 33731 9737 1015808 36829 36870
24159 45073 48831)
Mount_id 120, transaction 9936647, desc block 1738,
commit block 1740: ( 16)
Mount_id 120, transaction 9936648, desc block 1741,
commit block 1750: ( 59424 40789 47578 47649 7733248
16 47717 46480)
Mount_id 120, transaction 9936649, desc block 1751,
commit block 1758: ( 47649 47578 16 7733248 47717
46480)
Mount_id 120, transaction 9936650, desc block 1759,
commit block 1766: ( 47649 47578 7733248 16 47717
46480)
Mount_id 120, transaction 9936651, desc block 1767,
commit block 1776: ( 47649 47578 7733248 16 47717
46480 14926 25296)
Mount_id 120, transaction 9936652, desc block 1777,
commit block 1784: ( 47578 47649 7733248 16 47717
46480)
Mount_id 120, transaction 9936653, desc block 1785,
commit block 1793: ( 47578 47649 7733248 16 47717
46480 47718)
Mount_id 120, transaction 9936654, desc block 1794,
commit block 1803: ( 47578 47649 7733248 16 47718
46480 54961 28273)
Mount_id 120, transaction 9936655, desc block 1804,
commit block 1829: ( 47649 47578 7733248 16 47718
46480 27702 10174 10165 14938 83232 33731 36988 9536
10534 8330 8342 27677 27674 8365 18184 27703 27999
10107)
Mount_id 120, transaction 9936656, desc block 1830,
commit block 1841: ( 47578 47649 7733248 16 47718
46480 32768 47719 33073 7766016)
Mount_id 120, transaction 9936657, desc block 1842,
commit block 1857: ( 14952 9431 14938 10174 33241
45073 43361 27994 47649 47578 7766016 16 47718 46480)
Mount_id 120, transaction 9936658, desc block 1858,
commit block 1866: ( 14926 47578 47649 7766016 16
47718 46480)
Mount_id 120, transaction 9936659, desc block 1867,
commit block 1872: ( 38869 48831 47649 47578)
Mount_id 120, transaction 9936660, desc block 1873,
commit block 1876: ( 38869 16)
Mount_id 120, transaction 9936661, desc block 1877,
commit block 1879: ( 16)
Mount_id 120, transaction 9936662, desc block 1880,
commit block 1882: ( 16)
Mount_id 120, transaction 9936663, desc block 1883,
commit block 1891: ( 48831 47649 47578 7766016 16
47718 46480)
Mount_id 120, transaction 9936664, desc block 1892,
commit block 1896: ( 48831 47578 47649)
Mount_id 120, transaction 9936665, desc block 1897,
commit block 1905: ( 48831 47649 47578 7766016 16
47718 46480)
Journal replaied
Fetching on-disk bitmap..done
Checking S+tree../  1 (of   2)/ 43 (of 152)/  1 (of
163)shrink_id_map: objectid map shrinked: used 4096, 5
blocks
/ 44 (of 152)/105 (of 170)shrink_id_map: objectid map
shrinked: used 4096, 5 blocks
/ 58 (of 152)/ 57 (of 167)shrink_id_map: objectid map
shrinked: used 4096, 5 blocks
/ 59 (of 167)shrink_id_map: objectid map shrinked:
used 4096, 5 blocks
/ 77 (of 167)shrink_id_map: objectid map shrinked:
used 4096, 5 blocks
/ 79 (of 167)shrink_id_map: objectid map shrinked:
used 4096, 5 blocks
/ 80 (of 167)shrink_id_map: objectid map shrinked:
used 4096, 5 blocks
/101 (of 152)/ 91 (of 130)grow_id_map: objectid map
expanded: used 5120, 5 blocks
/117 (of 152)/ 80 (of 128)grow_id_map: objectid map
expanded: used 10240, 10 blocks
/125 (of 152)/121 (of 170)shrink_id_map: objectid map
shrinked: used 9216, 10 blocks
/  2 (of   2)/ 57 (of 150)/ 31 (of  85)grow_id_map:
objectid map expanded: used 5120, 5 blocks
/ 58 (of 150)/ 88 (of 170)grow_id_map: objectid map
expanded: used 5120, 5 blocks
/134 (of 170)grow_id_map: objectid map expanded: used
5120, 5 blocks
/ 65 (of 150)/148 (of 161)grow_id_map: objectid map
expanded: used 5120, 5 blocks
/ 68 (of 150)/131 (of 145)grow_id_map: objectid map
expanded: used 5120, 5 blocks
/ 88 (of 150)/  2 (of 156)shrink_id_map: objectid map
shrinked: used 4096, 5 blocks
/ 30 (of 156)shrink_id_map: objectid map shrinked:
used 4096, 5 blocks
/ 32 (of 156)shrink_id_map: objectid map shrinked:
used 4096, 5 blocks
/ 89 (of 150)/ 89 (of 169)block 7766332 is not marked
as used in the disk bitmap
block 7766211 is not marked as used in the disk bitmap
block 7766212 is not marked as used in the disk bitmap
block 7766213 is not marked as used in the disk bitmap
block 7766219 is not marked as used in the disk bitmap
block 7766227 is not marked as used in the disk bitmap
block 7766228 is not marked as used in the disk bitmap
block 7766229 is not marked as used in the disk bitmap
block 7766231 is not marked as used in the disk bitmap
block 7766232 is not marked as used in the disk bitmap
block 7766233 is not marked as used in the disk bitmap
block 7766234 is not marked as used in the disk bitmap
block 7766235 is not marked as used in the disk bitmap
block 7766236 is not marked as used in the disk bitmap
block 7766239 is not marked as used in the disk bitmap
block 7766240 is not marked as used in the disk bitmap
block 7766241 is not marked as used in the disk bitmap
block 7766242 is not marked as used in the disk bitmap
block 7766243 is not marked as used in the disk bitmap
block 7766244 is not marked as used in the disk bitmap
block 7766245 is not marked as used in the disk bitmap
block 7766246 is not marked as used in the disk bitmap
block 7766247 is not marked as used in the disk bitmap
block 7766248 is not marked as used in the disk bitmap
block 7766249 is not marked as used in the disk bitmap
block 7766250 is not marked as used in the disk bitmap
block 7766252 is not marked as used in the disk bitmap
block 7766253 is not marked as used in the disk bitmap
block 7766254 is not marked as used in the disk bitmap
block 7766255 is not marked as used in the disk bitmap
block 7766256 is not marked as used in the disk bitmap
block 7766257 is not marked as used in the disk bitmap
block 7766258 is not marked as used in the disk bitmap
block 7766259 is not marked as used in the disk bitmap
block 7766260 is not marked as used in the disk bitmap
block 7766261 is not marked as used in the disk bitmap
block 7766262 is not marked as used in the disk bitmap
block 7766263 is not marked as used in the disk bitmap
block 7766264 is not marked as used in the disk bitmap
block 7766265 is not marked as used in the disk bitmap
block 7766266 is not marked as used in the disk bitmap
block 7766267 is not marked as used in the disk bitmap
block 7766268 is not marked as used in the disk bitmap
block 7766269 is not marked as used in the disk bitmap
block 7766270 is not marked as used in the disk bitmap
block 7766271 is not marked as used in the disk bitmap
block 7766272 is not marked as used in the disk bitmap
block 7766273 is not marked as used in the disk bitmap
block 7766274 is not marked as used in the disk bitmap
block 7766275 is not marked as used in the disk bitmap
block 7766276 is not marked as used in the disk bitmap
block 7766277 is not marked as used in the disk bitmap
block 7766278 is not marked as used in the disk bitmap
block 7766279 is not marked as used in the disk bitmap
block 7766280 is not marked as used in the disk bitmap
block 7766282 is not marked as used in the disk bitmap
block 7766283 is not marked as used in the disk bitmap
block 7766284 is not marked as used in the disk bitmap
block 7766285 is not marked as used in the disk bitmap
block 7766286 is not marked as used in the disk bitmap
block 7766287 is not marked as used in the disk bitmap
block 7766288 is not marked as used in the disk bitmap
block 7766289 is not marked as used in the disk bitmap
block 7766290 is not marked as used in the disk bitmap
block 7766291 is not marked as used in the disk bitmap
block 7766292 is not marked as used in the disk bitmap
block 7766293 is not marked as used in the disk bitmap
block 7766294 is not marked as used in the disk bitmap
block 7766295 is not marked as used in the disk bitmap
block 7766296 is not marked as used in the disk bitmap
block 7766297 is not marked as used in the disk bitmap
block 7766298 is not marked as used in the disk bitmap
block 7766299 is not marked as used in the disk bitmap
block 7766300 is not marked as used in the disk bitmap
block 7766301 is not marked as used in the disk bitmap
block 7766302 is not marked as used in the disk bitmap
block 7766303 is not marked as used in the disk bitmap
block 7766304 is not marked as used in the disk bitmap
block 7766305 is not marked as used in the disk bitmap
block 7766306 is not marked as used in the disk bitmap
block 7766307 is not marked as used in the disk bitmap
block 7766308 is not marked as used in the disk bitmap
block 7766309 is not marked as used in the disk bitmap
block 7766310 is not marked as used in the disk bitmap
block 7766311 is not marked as used in the disk bitmap
block 7766312 is not marked as used in the disk bitmap
block 7766313 is not marked as used in the disk bitmap
block 7766314 is not marked as used in the disk bitmap
block 7766315 is not marked as used in the disk bitmap
block 7766316 is not marked as used in the disk bitmap
block 7766317 is not marked as used in the disk bitmap
block 7766318 is not marked as used in the disk bitmap
block 7766319 is not marked as used in the disk bitmap
block 7766320 is not marked as used in the disk bitmap
block 7766321 is not marked as used in the disk bitmap
block 7766322 is not marked as used in the disk bitmap
block 7766323 is not marked as used in the disk bitmap
block 7766324 is not marked as used in the disk bitmap
block 7766325 is not marked as used in the disk bitmap
block 7766326 is not marked as used in the disk bitmap
block 7766327 is not marked as used in the disk bitmap
block 7766328 is not marked as used in the disk bitmap
block 7766329 is not marked as used in the disk bitmap
block 7766330 is not marked as used in the disk bitmap
block 7766331 is not marked as used in the disk bitmap
/115 (of 150)/132 (of 143)shrink_id_map: objectid map
shrinked: used 4096, 5 blocks
ok
Comparing bitmaps..free block count 1214444 mismatches
with a correct one 1214339.
byte 970776: bm1: 0 bm2 38
byte 970777: bm1: 0 bm2 8
byte 970778: bm1: 40 bm2 fffffff8
byte 970779: bm1: 0 bm2 ffffff9f
byte 970780: bm1: 0 bm2 ffffffff
byte 970781: bm1: 8 bm2 ffffffff
byte 970782: bm1: 0 bm2 ffffffff
byte 970783: bm1: 0 bm2 ffffffff
byte 970784: bm1: 0 bm2 ffffffff
byte 970785: bm1: 2 bm2 ffffffff
byte 970786: bm1: 0 bm2 ffffffff
byte 970787: bm1: 0 bm2 ffffffff
byte 970788: bm1: 0 bm2 ffffffff
byte 970789: bm1: 0 bm2 ffffffff
byte 970790: bm1: 0 bm2 ffffffff
byte 970791: bm1: 0 bm2 1f
on-disk bitmap does not match to the correct one. 16
bytes differ
ok
Checking Semantic
t/opt/AVEngine/registry/hkey_current_user/software/computerassociates/inoculateit/6.0/local_scanner/stop_at_first_virus_in_a/tmp/recover.2.30031file
9 106855 has wrong sd_size 56377344, has to be
60522496
/scratch/UPS
SHIPPING/UPS/Common/SuppAsst/Tuner/vendors/ups/maps/com/ups/supportassistant/WorldShip/guides/Communications_Modem_Guidelet.mzp.t/ups
hosed
7-02/UPS/Common/SuppAsst/Tuner/vendors/ups/maps/com/ups/supportassistant/WorldShip/guides/Communications_Network_Information_Guidelok
ok


__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

Re: File Corruption

[Oleg Drokin]

Hello!

On Mon, Sep 30, 2002 at 12:52:27PM -0700, jeff leads wrote:
> Ok, I'm running RedHat 7.1, gcc 2.96-85, kernel
> 2.4.9-21 (redhat's version) and ReiserFSProgs 3.6.3 (

I do not know what is included into 2.4.9-21, but can you upgrade to
2.4.18-10 (I think this is latest RedHat errata kernel for 7.x series of
their distro).

> I'm starting to get file corruption here and there. 
> My next question is, where do I go from here?  What

You need to upgrade kernel to something that includes all of our fixes at least
up to 2.4.18.

> can I do to rectify this issue?  Do I run a rebuild at
> this point?  What caused this?  

This is hard to tell what have caused this.
Can you please send us reiserfsck output from the same partition,
but take reiserfsck from ReiserFSProgs 3.6.3?

> Sep 30 14:03:11 goku kernel: is_tree_node: node level
> 64680 does not match to the expected one 1

This is on disk metadata corruption, but the reason is unknown

> [root@goku /root]# reiserfsck /dev/ida/c0d0p5
> <-------------reiserfsck, 2001------------->
> reiserfsprogs 3.x.0j

This is too old to be used today.

Bye, 
    Oleg 

Re: File Corruption

[jeff leads]

Hi!  Below is the abbreviated version of my output
from --check.  Is it safe to run --fix-fixable?
 What do the bad nlink numbers mean?  Should I be
concerned about the dirty buffers?

Thanks again in advance!

Jeff 

], SD has bad nlink number
/  4 (of 143)bad_stat_data: block 46863, [124457 36663
0x0 SD (0)], SD has bad n
link number
/  5 (of 143)bad_stat_data: block 44550, [124457
101732 0x0 SD (0)], SD has bad
nlink number
bad_stat_data: block 44550, [124457 114743 0x0 SD
(0)], SD has bad nlink number
bad_stat_data: block 44550, [124457 124458 0x0 SD
(0)], SD has bad nlink number
bad_stat_data: block 44550, [124457 124469 0x0 SD
(0)], SD has bad nlink number
/  6 (of 143)bad_stat_data: block 63760, [124457
151128 0x0 SD (0)], SD has bad
nlink number
/125 (of 160)/ 32 (of 163)bad_stat_data: block 47631,
[143160 155080 0x0 SD (0)]
, SD has bad nlink number
bad_stat_data: block 47631, [143160 155192 0x0 SD
(0)], SD has bad nlink number
ok
Comparing bitmaps..ok
Checking Semantic tree...
/tmp/recover.2.30031file 9 106855 has wrong sd_size
56377344, has to be 60522496
file 9 106855 has wrong sd_blocks 0, has to be 118208
ok
There were found 102 corruptions which can be fixed
with --fix-fixable
check_and_free_buffer_mem: dirty buffer (3 16) found
###########
reiserfsck finished at Tue Oct  1 19:32:45 2002
--- Oleg Drokin <green@namesys.com> wrote:
> Hello!
> 
> On Mon, Sep 30, 2002 at 12:52:27PM -0700, jeff leads
> wrote:
> > Ok, I'm running RedHat 7.1, gcc 2.96-85, kernel
> > 2.4.9-21 (redhat's version) and ReiserFSProgs
> 3.6.3 (
> 
> I do not know what is included into 2.4.9-21, but
> can you upgrade to
> 2.4.18-10 (I think this is latest RedHat errata
> kernel for 7.x series of
> their distro).
> 
> > I'm starting to get file corruption here and
> there. 
> > My next question is, where do I go from here? 
> What
> 
> You need to upgrade kernel to something that
> includes all of our fixes at least
> up to 2.4.18.
> 
> > can I do to rectify this issue?  Do I run a
> rebuild at
> > this point?  What caused this?  
> 
> This is hard to tell what have caused this.
> Can you please send us reiserfsck output from the
> same partition,
> but take reiserfsck from ReiserFSProgs 3.6.3?
> 
> > Sep 30 14:03:11 goku kernel: is_tree_node: node
> level
> > 64680 does not match to the expected one 1
> 
> This is on disk metadata corruption, but the reason
> is unknown
> 
> > [root@goku /root]# reiserfsck /dev/ida/c0d0p5
> > <-------------reiserfsck, 2001------------->
> > reiserfsprogs 3.x.0j
> 
> This is too old to be used today.
> 
> Bye, 
>     Oleg 


__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

Re: File Corruption

[Oleg Drokin]

Hello!

On Tue, Oct 01, 2002 at 09:07:34PM -0700, jeff leads wrote:

> Hi!  Below is the abbreviated version of my output
> from --check.  Is it safe to run --fix-fixable?

Hm. No signs of that bad corruption your kernel was reporting.

>  What do the bad nlink numbers mean?  Should I be

These are "lost" files most probably. Bad nlink means that file have
nlink count of zero.

> concerned about the dirty buffers?

Hm. Can you get resiserfsprogs 3.6.4-pre3 from our ftp site
(ftp://ftp.namesys.com/pub/reiserfsprogs/pre) and give it a try,
if this "dirty buffers" message persists, please take metadata snapshot for us
( debugreiserfs -p /dev/your_device | gzip -9c >metadata.gz ).
Also resiserfsprogs 3.6.4-pre3 would tell you that you need
rebuild tree most probably (because now nlink number correction is only done
on rebuild-tree stage), so you would need to do rebuild-tree.

Bye,
    Oleg

Re: File corruption

[Ulf Carlsson]

On Tue, Jun 22, 1999 at 03:21:45PM +0200, Ralf Baechle wrote:
> On Tue, Jun 22, 1999 at 03:29:00AM +0200, Ulf Carlsson wrote:
> 
> > This is *really* annoying, I can't do anything without getting interrupted
> > by some bug on the Indy.  I can't stand this file corruption.  I just lost
> > an entire directory.  This isn't because of crashes, stuff just vanish, or
> > gets corrupted without any reason.  I for example had a gzipped patch, I
> > decompressed it and I got a lot of junk in the middle of the file.
> 
> Question, is this effect repeatable, that is if you decompress the file a
> second time, will you still see the filesystem corruption?  The latter would
> mean that the data decompressed data get corrupted on the fly and the SCSI
> driver isn't involved.  Or does the gzip'ed file itself already contain the
> corrupted data?

Since the file is decompressed without warnings I assume that the scp went fine.
Anyhow, when I had decompressed the file I got corruption in the middle of the
patch.  The corruption affected only a couple of lines, 10 or so.

The problems I experience are not repeatable.  Everything went smooth after a
reboot.  I usually reboot the machine when it's messing with me, that helps.  At
least for a while.

> And under which kernel version did this start to happen?

2.2.1 I think.

> Could you resend me your hinv output?

Unfortunately I don't have IRIX.  However, I have a 133 MHz R4600 CPU with 512 k
board cache.  I have two 1 Gb SCSI driver connected.

> > Earlier today the cached version of /lib/libpam_misc.so.0.64 was corrupted
> > or something, and corrupted ELF headers were reported.  A reboot fixed that
> > one.
> 
> It seems that you observe similar problems like me.  For me however the
> problem has just vanished and was rare anyway.

They're rare for me as well, but I've had a couple in just a few days now.
Maybe the file corruption became heavier since 2.3.6?

> I understand that very well.  Btw, I started to store important stuff on NFS.

I can't stand NFS. Files, or entire directories vanish from ls, but I may still
open them if I specify their names directly.  I think I've been talking to you
about this before.

- Ulf

Re: File corruption

[Ralf Baechle]

On Wed, Jun 23, 1999 at 01:49:23AM +0200, Ulf Carlsson wrote:

> > And under which kernel version did this start to happen?
> 
> 2.2.1 I think.

Are you shure?  The problem Alan is tracking started to hit from 2.2.7 on.
If 2.2.1 already starts making these kind of troubles then we probably
track two different problems.

> Unfortunately I don't have IRIX.  However, I have a 133 MHz R4600 CPU with 512 k
> board cache.  I have two 1 Gb SCSI driver connected.

Is this a low-mem configuration?  The problem Alan is tracking apparently
seems to hit low mem systems more often.

  Ralf

Re: File corruption

[Ulf Carlsson]

> > > And under which kernel version did this start to happen?
> > 
> > 2.2.1 I think.
> 
> Are you shure?  The problem Alan is tracking started to hit from 2.2.7 on.  If
> 2.2.1 already starts making these kind of troubles then we probably track two
> different problems.

Probably.  I have a new problem with the 2.3.8 kernel now as well:  Page->owner
becomes -1 at line 1218 in buffer.c, thus forcing an oops.  This happens when I
try to cat a couple of big files into a new file.  This is even reproduceable...

I get some error messages before the oops as well:

attempt to access beyond end of device
08:01: rw=0, want=122156967, limit=929559
attempt to access beyond end of device
08:01: rw=0, want=886680107, limit=929559

> > Unfortunately I don't have IRIX.  However, I have a 133 MHz R4600 CPU with
> > 512 k board cache.  I have two 1 Gb SCSI driver connected.
> 
> Is this a low-mem configuration?  The problem Alan is tracking apparently
> seems to hit low mem systems more often.

Not really, I have 128 Mb RAM, but no swap.

Regards,
Ulf

Re: File corruption

[Thomas Bogendoerfer]

On Fri, Jun 25, 1999 at 03:31:08PM +0200, Ulf Carlsson wrote:
> Probably.  I have a new problem with the 2.3.8 kernel now as well:  Page->owner
[...]
> I get some error messages before the oops as well:
> 
> attempt to access beyond end of device
> 08:01: rw=0, want=122156967, limit=929559
> attempt to access beyond end of device
> 08:01: rw=0, want=886680107, limit=929559

this seems to be a normal 2.3 error. At least I get this impression, when
reading the linux-kernel mailinglist.

Thomas.

-- 
   This device has completely bogus header. Compaq scores again :-|
It's a host bridge, but it should be called ghost bridge instead ;^)
                                        [Martin `MJ' Mares on linux-kernel]

Re: File corruption

[Andrew Linfoot]

I have been running 2.2.1 on my indy for about 3 weeks now and have
encountered problems like this,
in fact i am surprised at how stable the box is, i have been doing some
quite large builds of qt, kde and the like too. If this is reproducible then
i would be prepared to experiment on one of my boxes.

The only gripe i have is that the scsi driver breaks when i attach external
devices, any ideas?

Andy
----- Original Message -----
From: Ralf Baechle <ralf@uni-koblenz.de>
To: <linux@cthulhu.engr.sgi.com>
Sent: Thursday, June 24, 1999 11:28 PM
Subject: Re: File corruption


> On Wed, Jun 23, 1999 at 01:49:23AM +0200, Ulf Carlsson wrote:
>
> > > And under which kernel version did this start to happen?
> >
> > 2.2.1 I think.
>
> Are you shure?  The problem Alan is tracking started to hit from 2.2.7 on.
> If 2.2.1 already starts making these kind of troubles then we probably
> track two different problems.
>
> > Unfortunately I don't have IRIX.  However, I have a 133 MHz R4600 CPU
with 512 k
> > board cache.  I have two 1 Gb SCSI driver connected.
>
> Is this a low-mem configuration?  The problem Alan is tracking apparently
> seems to hit low mem systems more often.
>
>   Ralf
>

Re: File corruption

[Andrew Linfoot]

I have been running 2.2.1 on my indy for about 3 weeks now and have
encountered problems like this,
in fact i am surprised at how stable the box is, i have been doing some
quite large builds of qt, kde and the like too. If this is reproducible then
i would be prepared to experiment on one of my boxes.

The only gripe i have is that the scsi driver breaks when i attach external
devices, any ideas?

Andy
----- Original Message -----
From: Ralf Baechle <ralf@uni-koblenz.de>
To: <linux@cthulhu.engr.sgi.com>
Sent: Thursday, June 24, 1999 11:28 PM
Subject: Re: File corruption


> On Wed, Jun 23, 1999 at 01:49:23AM +0200, Ulf Carlsson wrote:
>
> > > And under which kernel version did this start to happen?
> >
> > 2.2.1 I think.
>
> Are you shure?  The problem Alan is tracking started to hit from 2.2.7 on.
> If 2.2.1 already starts making these kind of troubles then we probably
> track two different problems.
>
> > Unfortunately I don't have IRIX.  However, I have a 133 MHz R4600 CPU
with 512 k
> > board cache.  I have two 1 Gb SCSI driver connected.
>
> Is this a low-mem configuration?  The problem Alan is tracking apparently
> seems to hit low mem systems more often.
>
>   Ralf
>

Re: File corruption

[Ulf Carlsson]

On Fri, Jun 25, 1999 at 03:34:15PM +0100, Andrew Linfoot wrote:
> I have been running 2.2.1 on my indy for about 3 weeks now and have
> encountered problems like this, in fact i am surprised at how stable the box
> is, i have been doing some quite large builds of qt, kde and the like too. If
> this is reproducible then i would be prepared to experiment on one of my
> boxes.

It doesn't crash, only file corruption..

> The only gripe i have is that the scsi driver breaks when i attach external
> devices, any ideas?

I have file corruption without any external devices.  It looks like the problems
appear when more than one SCSI devices are present.  You only have one internal
SCSI drive, right?

Do you mind telling us more exactly what type of file corruption you suffer
from?  It would also help if you could attach an output from hinv, or just tell
us what hardware you have.

Regards,
Ulf

Re: File corruption

[Andrew Linfoot]

On a couple of occasions i have lost entire directories but this was some
time ago
----- Original Message -----
From: Ulf Carlsson <ulfc@thepuffingroup.com>
To: Andrew Linfoot <andy@derfel99.freeserve.co.uk>
Cc: <linux@cthulhu.engr.sgi.com>
Sent: Friday, June 25, 1999 5:59 PM
Subject: Re: File corruption


> On Fri, Jun 25, 1999 at 03:34:15PM +0100, Andrew Linfoot wrote:
> > I have been running 2.2.1 on my indy for about 3 weeks now and have
> > encountered problems like this, in fact i am surprised at how stable the
box
> > is, i have been doing some quite large builds of qt, kde and the like
too. If
> > this is reproducible then i would be prepared to experiment on one of my
> > boxes.
I have had a couple of instances where i lost complete directories, but this
was during the first few days of running Linux on my box, i simply put it
down to operator error!
>
> It doesn't crash, only file corruption..
>
> > The only gripe i have is that the scsi driver breaks when i attach
external
> > devices, any ideas?
>
> I have file corruption without any external devices.  It looks like the
problems
> appear when more than one SCSI devices are present.  You only have one
internal
> SCSI drive, right?
2 drives - see below
If i attempt to attach an external device the system just hangs during scsi
initialisation. I think this is fixed in later kernels but i don't have cvs
up yet so i can't move past 2.2.1.
>
> Do you mind telling us more exactly what type of file corruption you
suffer
> from?  It would also help if you could attach an output from hinv, or just
tell
> us what hardware you have.
CPU: MIPS-R4400 FPU<MIPS-R4400FPC> ICACHE DCACHE SCACHE
Loading R4000 MMU routines.
CPU revision is: 00000450
Primary instruction cache 16kb, linesize 16 bytes)
Primary data cache 16kb, linesize 16 bytes)
Secondary cache sized at 1024K linesize 128
8-bit graphics
128MB RAM
sda 540MB with base IRIX
sdb 2GB with Linux.and swap

an interesting point here is that /proc/cpuinfo tells me i only have an
r4000!

Andy
>
> Regards,
> Ulf
>

Re: File corruption

[Andrew Linfoot]

On a couple of occasions i have lost entire directories but this was some
time ago
----- Original Message -----
From: Ulf Carlsson <ulfc@thepuffingroup.com>
To: Andrew Linfoot <andy@derfel99.freeserve.co.uk>
Cc: <linux@cthulhu.engr.sgi.com>
Sent: Friday, June 25, 1999 5:59 PM
Subject: Re: File corruption


> On Fri, Jun 25, 1999 at 03:34:15PM +0100, Andrew Linfoot wrote:
> > I have been running 2.2.1 on my indy for about 3 weeks now and have
> > encountered problems like this, in fact i am surprised at how stable the
box
> > is, i have been doing some quite large builds of qt, kde and the like
too. If
> > this is reproducible then i would be prepared to experiment on one of my
> > boxes.
I have had a couple of instances where i lost complete directories, but this
was during the first few days of running Linux on my box, i simply put it
down to operator error!
>
> It doesn't crash, only file corruption..
>
> > The only gripe i have is that the scsi driver breaks when i attach
external
> > devices, any ideas?
>
> I have file corruption without any external devices.  It looks like the
problems
> appear when more than one SCSI devices are present.  You only have one
internal
> SCSI drive, right?
2 drives - see below
If i attempt to attach an external device the system just hangs during scsi
initialisation. I think this is fixed in later kernels but i don't have cvs
up yet so i can't move past 2.2.1.
>
> Do you mind telling us more exactly what type of file corruption you
suffer
> from?  It would also help if you could attach an output from hinv, or just
tell
> us what hardware you have.
CPU: MIPS-R4400 FPU<MIPS-R4400FPC> ICACHE DCACHE SCACHE
Loading R4000 MMU routines.
CPU revision is: 00000450
Primary instruction cache 16kb, linesize 16 bytes)
Primary data cache 16kb, linesize 16 bytes)
Secondary cache sized at 1024K linesize 128
8-bit graphics
128MB RAM
sda 540MB with base IRIX
sdb 2GB with Linux.and swap

an interesting point here is that /proc/cpuinfo tells me i only have an
r4000!

Andy
>
> Regards,
> Ulf
>

Re: File corruption

[Ralf Baechle]

On Fri, Jun 25, 1999 at 06:11:52PM +0100, Andrew Linfoot wrote:

> CPU: MIPS-R4400 FPU<MIPS-R4400FPC> ICACHE DCACHE SCACHE

This is what the firmware detected.

> Loading R4000 MMU routines.

This will always say R4000 if it's a R4000 class CPU.

> CPU revision is: 00000450
> Primary instruction cache 16kb, linesize 16 bytes)
> Primary data cache 16kb, linesize 16 bytes)
> Secondary cache sized at 1024K linesize 128

Which says that you have an R4400SC V5.0.

> an interesting point here is that /proc/cpuinfo tells me i only have an
> r4000!

Good spotting, the CPU detection code has a bug causes only V4 CPUs to be
detected as R4400.  The difference is just cosmetics; R4000 and R4400 are
almost the same.  Especially it's unrelated to the file corruption problem.

  Ralf

Re: File corruption

[Ralf Baechle]

On Fri, Jun 25, 1999 at 03:34:15PM +0100, Andrew Linfoot wrote:

> I have been running 2.2.1 on my indy for about 3 weeks now and have
> encountered problems like this,
> in fact i am surprised at how stable the box is, i have been doing some
> quite large builds of qt, kde and the like too. If this is reproducible then
> i would be prepared to experiment on one of my boxes.
> 
> The only gripe i have is that the scsi driver breaks when i attach external
> devices, any ideas?

There is nothings special with external devices, so if they result in
crashes you should double check that cabeling and termination are ok.

  Ralf