On 22 July 2010 19:07, Johannes Hirte <johannes.hirte@xxxxxxxxxxxxxxxxx> wrote: > Am Montag 19 Juli 2010, 10:01:46 schrieb Miao Xie: >> On Thu, 15 Jul 2010 20:14:51 +0200, Johannes Hirte wrote: >> > Am Donnerstag 15 Juli 2010, 02:11:04 schrieb Dave Chinner: >> >> On Wed, Jul 14, 2010 at 05:25:23PM +0200, Johannes Hirte wrote: >> >>> Am Donnerstag 08 Juli 2010, 16:31:09 schrieb Chris Mason: >> >>> I'm not sure if btrfs is to blame for this error. After the errors I >> >>> switched to XFS on this system and got now this error: >> >>> >> >>> ls -l .kde4/share/apps/akregator/data/ >> >>> ls: cannot access .kde4/share/apps/akregator/data/feeds.opml: Structure >> >>> needs cleaning >> >>> total 4 >> >>> ?????????? ? ? ? ? ? feeds.opml >> >> >> >> What is the error reported in dmesg when the XFS filesytem shuts down? >> > >> > Nothing. I double checked the logs. There are only the messages when >> > mounting the filesystem. No other errors are reported than the >> > inaccessible file and the output from xfs_check. >> >> Is there anything wrong with your disks or memory? >> Sometimes the bad memory can break the filesystem. I have met this kind of >> problem some time ago. > > I don't think that's the case. I've checked the RAM with memtest86+ and got no > errors. I got the errors with two different disks, the first one with btrfs the > second one now with XFS. Before changing to the second disk, I've run > badblocks on it to be sure it has no errors. There are some known-buggy chipsets also. One still around is the Nvidia CK804/MCP55, under certain patterns of spatially-local pending reads and writes to the memory controller, a 64-byte request would occasionally be returned with the wrong offset. I was hitting it with some 27-Gbit adapters and managed to capture it on a PCI-e protocol analyser. Rsync between network and local disk would hit sometimes too. -- Daniel J Blueman -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
