Hi Michael, On Mon, Aug 15, 2011 at 1:56 AM, Michael Tokarev <mjt@xxxxxxxxxx> wrote: > 15.08.2011 12:00, Michael Tokarev wrote: > [....] > > So, it looks like this (starting with cold cache): > > 1. rename the redologs and copy them over - this will > make a hot copy of redologs > 2. startup oracle - it will complain that the redologs aren't > redologs, the header is corrupt > 3. shut down oracle, start it up again - it will succeed. > > If between 1 and 2 you'll issue sync(1) everything will work. > When shutting down, oracle calls fsync(), so that's like > sync(1) again. > > If there will be some time between 1. and 2., everything > will work too. > > Without dioread_nolock I can't trigger the problem no matter > how I tried. > > > A smaller test case. I used redo1.odf file (one of the > redologs) as a test file, any will work. > > $ cp -p redo1.odf temp > $ dd if=temp of=foo iflag=direct count=20 Isn't this the expected behavior here? When doing 'cp -p redo1.odf temp', data is copied to temp through buffer write, but there is no guarantee when data will be actually written to disk. Then with 'dd if=temp of=foo iflag=direct count=20', data is read directly from disk. Very likely, the written data hasn't been flushed to disk yet so ext4 returns zero in this case. Jiaying > > Now, first 512bytes of "foo" will contain all zeros, while > the beginning of redo1.odf is _not_ zeros. > > Again, without aioread_nolock it works as expected. > > > And the most important note: without the patch there's no > data corruption like that. But instead, there is the > lockup... ;) > > Thank you, > > /mjt > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
