xfs
[Top] [All Lists]

RE: sync doesn't do the job

To: Jason Li <jli@xxxxxxxxxxx>
Subject: RE: sync doesn't do the job
From: Eric Sandeen <sandeen@xxxxxxx>
Date: 19 Feb 2003 19:38:00 -0600
Cc: "'linux-xfs@xxxxxxxxxxx'" <linux-xfs@xxxxxxxxxxx>
In-reply-to: <7CBD7127AB037F439CB8146275AE261E37CEBA@hq-ex-6>
References: <7CBD7127AB037F439CB8146275AE261E37CEBA@hq-ex-6>
Sender: linux-xfs-bounce@xxxxxxxxxxx
Jason - one other thing that occurred to me...  does the CF system do
write-caching?  Might be interesting to test this on a spinning disk, if
you can.  (and if it's IDE, explicitly turn off write caching).

I tried the reboot -f test on essentially top of tree devel code, on a
scsi drive, and it worked fine.

I also tested it on 1.1 code (which we released for vanilla kernel
2.4.18, and Red Hat 2.4.9-based - I tested the Red Hat kernel), and it
also worked fine.

(I left out the "(show dirty buffers)" part, not sure what you're doing
there.)

You said it's 1.1 on linux 2.4.19 - I wonder if the forward port may
have caused problems?

-Eric

On Wed, 2003-02-19 at 19:18, Jason Li wrote:
> 
> Hi Eric,
> 
> Thanks for replying.
> 
> I tried the following script:
>       for i in `seq 1 100` do echo $i>>myfile done;
>       sync
>       (show dirty buffers)
>       reboot -f
> and
>       for i in `seq 1 100` do echo $i>>myfile done;
>       sync
>       (show dirty buffers)
>       mount -ro /
>       reboot
> Both failed to get the 100 numbers in the file.
> 
> Another thing I tried is to show dirty buffers (with a hack) -- both showed
> no dirty buffer from the linux side.
> 
> We can try 1.2, but for now we need to understand where the problem is.
> 
> Best regards,
> Jason



<Prev in Thread] Current Thread [Next in Thread>