Rajagopal Ananthanarayanan wrote:
> Russell Cattelan wrote:
> >
> > Rajagopal Ananthanarayanan wrote:
> >
> > > Russell Cattelan wrote:
> > > >
> > > > Modid: 2.3.99pre2-xfs:slinx:61503a
> > > > Date: Fri May 12 11:49:04 PDT 2000
> > > > Workarea: nt8.americas.sgi.com:/data/clink/io/cattelan/x2.3-99-xfs
> > > > Author: cattelan
> > > >
> > > > The following file(s) were checked into:
> > > > bonnie.engr.sgi.com:/isms/slinx/2.3.99pre2-xfs
> > > >
> > > > linux/fs/page_buf.c - 1.92
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> > > >
linux/fs/page_buf.c.diff?r1=text&tr1=1.92&r2=text&tr2=1.91&f=h
> > > > - Fix for file long outstanding file corruption.
> > > > Need to set invalid bits on new page returned from
> > > > grab_cache_page
> > > > so prepare_file_write will know to read the page from disk
> > > > if not on a page boundry.
> > > > Also turn off delay alloc; it has problems in the same area
> > > > and will currently cause file corruption.
> > >
> > > You may have something here. But grab_page_cache
> > > can return an existing page .. in which case
> > > you can't set blocks invalid. That would be
> > > equivalent to throwing away dirty pages.
> >
> > yes... in fact I commented about that.
> > But given the io lock is held and pb_generic_write_file looks at the
> > hash first, the only time we should be calling grab_cache_page is when
> > a new pages is needed.
> >
> > We need to look at what pg_lookup_pages does, and possibly implement
> > a pb_grab_cache_page.
> >
> > Also the delay alloc code needs to be looked at since it seems to
> > looking at the vaild bits wrong. It appears to assume a page is
> > Valid when is it allocated which is true because we are
> > never setting it invalid. But the rest of the code works
> > the otherway around...
> >
>
> [ Taking this discussion back to slinx-xfs; linux-xfs@oss doesn't
> deliver messages in time ]
>
> To simplify things, lets deal only with non-delalloc cases.
>
> With the above change & tot tree, I'm still seeing corruption
> with doio running with only 2 threads, and with kernel makes.
> The corruption signatures are the same as its always been.
> doio-2 fails a mmap-write data check. Kernel make is seeing
> source corruption.
Is the source file on disk corrupted or just cached buffer?
in other words if you unmount the file system and remount it is the source file
still
corrupted?
I haven't been able to get doio to corrupt... I know jim was running with 5
threads
successfully.
>
>
> Are you running with only 64M of memory?
no
|