Re: XFS fails fsx-linux.c (1 charactor difference)

[Stephen Lord <lord@xxxxxxx>]

Shawn Starr wrote:

> sure:
>
> http://www.codemonkey.org.uk/cruft/fsx-linux.c
>
> Shawn.
>
> On Sun, 6 Jan 2002, Stephen Lord wrote:
>
> > Shawn Starr wrote:
> >
> > > With an exaustive test running overnight with the new -mjc branch of 2.4
> > > (I'm working on getting XFS into the branch) I noticed the following
> > > fault:
> > >
> > > truncating to largest ever: 0x3fcb9
> > > READ BAD DATA: offset = 0x53e5, size = 0x9c0a
> > > OFFSET  GOOD    BAD     RANGE
> > > 0x 9000 0x0000  0x0101  0x 5faa
> > > operation# (mod 256) for the bad data may be 1
> > > LOG DUMP (1145 total operations):
> > >
> > > I have attached the dump of the results run and the binary difference is
> > > ONE charactor:
> > >
> > > cmp boom boom.fsxgood
> > > boom boom.fsxgood differ: char 10428, line 18
> > >
> > > It would be a good idea to use the fsx-linux.c program to stress test XFS.
> > > The fsx-linux program has found several bugs in NFS and other filesystems.
> > >
> > > Shawn.
> > Google does not have any references to this program - can you provide a
> > pointer?
> >
> > Thanks
> >
> >   Steve
Ah ha, I have seen this program before (under a slightly different name) 
it was running just fine
on XFS when I last ran it. On the other hand we appear to be suffering 
from a regression
right now, and if I am correct, the regression happened right around the 
day I last ran
this program, so it is possible the same change broke fsx as well as 
emacs builds....

Steve