Bug 2155

Was the file in question on the root filesystem?  Can you verify that
it is only a problem on /, and not on other filesystems?  This may
be a problem with the remount,readonly code that the system goes
through for root (/) when shutting down.

The problem definitely occured on XFS partition. My all partitions run on XFS 
except /boot running on reiserfs.

I'll take chance to try that on /boot to see if it's directly related to XFS.

My another problem is 

Couple of days ago, I installed debsums(debsums is a debian tool like tripwire) 
on my sarge box, debsums reported some files under /usr are checksum mismatch.
(I am sure system is not compromised)
I reinstalled those damaged file and keep observing.

Since then, everyday, there will be one or two files got reported as
checksum mismatch. I have run diff to double checked that. 
Those files are still usable tho.

And if I just leave those changed files alone, sometimes, couple of hours
later, debsums might report no error.
There is any error message about this dmesg.

I don't think it's a hardware problem.

And probably this problem has some relation with the first one.



The following files are checksum mismatch mostly. Most are system files.


debsums: checksum mismatch links file usr/bin/links.main
debsums: checksum mismatch dpkg file usr/bin/dpkg
debsums: checksum mismatch libglib2.0-0 file usr/lib/libglib-2.0.so.0.200.3
debsums: checksum mismatch sysstat file usr/bin/iostat
debsums: checksum mismatch libglib2.0-0 file usr/lib/libglib-2.0.so.0.200.3
debsums: checksum mismatch python2.3 file usr/lib/python2.3/Cookie.py

s/There is any error message about this dmesg./There is no error message about 
this in demsg./

*** Bug 2336 has been marked as a duplicate of this bug. ***

The problem seems related to all XFS filesystems on LVM, LVM2 and RAID, root and
non-root.

The comment #3 seems to be a different issue, sth that is related to "read".

I've tried #3 on kernel 2.4.25, same problem.

Can I try to isolate the bug code with debugging on or with other way?

Hi, Emilio

Do you mean "Can you try to..."?

Hi, Cheng
I will offer my capacity of reproduce the issue for identify the code that
generate this issue.
Perhaps if you have already an idea about it, please tell us.
I think that there is a relation between gcc and this bug. If i use gcc 3.2.3 i
have similar issues with 2.4.25, but not the same. If i use gcc 3.3.1 the 2.4.25
works fine.
With 2.6.x xfs on LVM or RAID is data-losser, with all gcc 3.X. I have not tried
gcc 2.9X.XX.
I'm not a hard coder, but perhaps i will be useful for XFS developer to isolate
the wrong code....
Thanks

Hi, Emilio 

Sorry for my delayed response.

The kernel that I encountered I/O sync problem (beginning message submitted in 
this bugreport) was compiled by GCC 3.3.3.


However, for the comment #3, it seems to be an independent issue. I've tried it 
with 2.4.25 and XFS/Reiserfs/Ext3 with or without LVM, the problem can be 
reproduced under all these conditions. 

Here is some interesting message you might be interested, and it happens on my 
box rulelessly and daily.

############################################################################
tux:/etc/init.d# debsums -s
debsums: checksum mismatch python2.3 file usr/lib/python2.3/Cookie.py

#debsums is a debian file integrity-check tool like tripwire
#Then I copied an intact Cookie.py from another system to diff

tux:/etc/init.d# diff /usr/lib/python2.3/Cookie.py /home/geek/Cookie.py 
467,469c467,468
<  uration state."""
<         if self._defaults:
<             fp.writ                        self.key, repr(self.value) )
---
>         return '<%s: %s=%s>' % (self.__class__.__name__,
>                                 self.key, repr(self.value) )

#Look at the first line:    uration state."""

#Let's run grep -r 'uration state.\"\"\"' in /usr/lib/python2.3/

tux:/usr/lib/python2.3# grep -r 'uration state.\"\"\"' * 
ConfigParser.py:        """Write an .ini-format representation of the 
configuration state."""
Cookie.py: uration state."""

#The mismatched content is actually some string from another file in the same 
direcotry. 

########################################################################

Really odd, huh?


I am not sure if the above two problems has any relation between them, or maybe 
I'd better submit the comment #3 as an indepdent bug?

I think also thath the #3 case must be classified as an indipendent bug.
This because non seems related to XFS sync with kernel 2.6.X.

Now we need the voice of XFS Guru and other LVM and RAID Guru, because I Have
not sufficient skill to find the wrong code.

Hi, XFS Guru's are you alive?
Thanks
Emilio Gargiulo

Is this issue still present in recent 2.6 kernels?

Please reopen this bug if it's still present with kernel 2.6.20.