Hi,
Following the discussion in another thread where someone
reported fs corruption when enabling DMA with hdparm, I've
played around with hdparm and found that even the rather
harmless hdparm operations are capable of trashing an ext2
filesystem quite nicely.
hdparm version is 3.9
hdparm -tT /dev/hdb1 does the trick here.
After that, several files are corrupted, such as /etc/mtab.
Reboot+fsck fixes the problem, however e2fsck never finds
any errors in the fs on disk.
I'm quite sure that earlier kernel versions didn't exhibit
this kind of behaviour, although I'm not quite sure at
which point things started to break. I have test12-pre6
here atm, but I have test-11 still lying around and will
test that in a bit.
The drive in question is an IBM-DTLA307030 running in
UDMA Mode 5 on a PDC20265, chipset revision 2.
I haven't seen any other corruption other than that which
hdparm reliably triggers. Might as well be a bug in hdparm,
so someone else might also want to check...
-Udo.
On Wed, Dec 06, 2000 at 06:25:15PM +0100, Udo A. Steinberg wrote:
> hdparm -tT /dev/hdb1 does the trick here.
>
> After that, several files are corrupted, such as /etc/mtab.
> Reboot+fsck fixes the problem, however e2fsck never finds
> any errors in the fs on disk.
I'm currently trying to isolate a bug that is triggered by invalidate_buffers
and leads to in-memory filesystem corruption.
As hdparm -tT AFAIK calls invalidate_buffers (through BLKFLSBUF),
this may be related.
Jan
On Wed, 6 Dec 2000, Udo A. Steinberg wrote:
> Hi,
>
> Following the discussion in another thread where someone
> reported fs corruption when enabling DMA with hdparm, I've
> played around with hdparm and found that even the rather
> harmless hdparm operations are capable of trashing an ext2
> filesystem quite nicely.
>
> hdparm version is 3.9
>
> hdparm -tT /dev/hdb1 does the trick here.
>
> After that, several files are corrupted, such as /etc/mtab.
> Reboot+fsck fixes the problem, however e2fsck never finds
> any errors in the fs on disk.
>
> I'm quite sure that earlier kernel versions didn't exhibit
> this kind of behaviour, although I'm not quite sure at
> which point things started to break. I have test12-pre6
> here atm, but I have test-11 still lying around and will
> test that in a bit.
I've seen this behavior on test-6 and up. I think it has something to do with
a problem in shared memory which is used by the 'hdparm -tT' code snippet. I
believe it munges over a lot of the memory segments that contain cached disk
files (the common ones accessed, such as /etc/mtab and /etc/utmp..etc). When
looking at the contents of those files, the memory is obtained from the cache
and they appear bogus, but on disk they are still correct.
If this problem occurs, it's best to hit the reset button so that no 'bad' data
is written back to disk during a sync call.
Can anyone else verify that the problem is in shared memory and not the disk
caching layer?
Regards,
Byron
--
Byron Stanoszek Ph: (330) 644-3059
Systems Programmer Fax: (330) 644-8110
Commercial Timesharing Inc. Email: [email protected]
No way that this could cause corruption it is a read-only test.
On Wed, 6 Dec 2000, Udo A. Steinberg wrote:
>
> Hi,
>
> Following the discussion in another thread where someone
> reported fs corruption when enabling DMA with hdparm, I've
> played around with hdparm and found that even the rather
> harmless hdparm operations are capable of trashing an ext2
> filesystem quite nicely.
>
> hdparm version is 3.9
>
> hdparm -tT /dev/hdb1 does the trick here.
>
> After that, several files are corrupted, such as /etc/mtab.
> Reboot+fsck fixes the problem, however e2fsck never finds
> any errors in the fs on disk.
>
> I'm quite sure that earlier kernel versions didn't exhibit
> this kind of behaviour, although I'm not quite sure at
> which point things started to break. I have test12-pre6
> here atm, but I have test-11 still lying around and will
> test that in a bit.
>
> The drive in question is an IBM-DTLA307030 running in
> UDMA Mode 5 on a PDC20265, chipset revision 2.
>
> I haven't seen any other corruption other than that which
> hdparm reliably triggers. Might as well be a bug in hdparm,
> so someone else might also want to check...
>
> -Udo.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
>
Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development
On Wed, Dec 06, 2000 at 11:41:51AM -0800, Andre Hedrick wrote:
> No way that this could cause corruption it is a read-only test.
It definitely does, I saw it, too. It seems to be triggered
by invalidate_buffers().
Jan
Hi,
Andre Hedrick wrote:
>
> No way that this could cause corruption it is a read-only test.
As others pointed out, it's probably something related to shared
memory, but it's definitely hdparm that triggers it. I haven't
got the hdparm sources here to look at what exactly it's doing,
but there is corruption going on, not on disk, but definitely in
memory.
-Udo.
Did you set and mount a "/var/shm" point?
On Wed, 6 Dec 2000, Udo A. Steinberg wrote:
> Hi,
>
> Andre Hedrick wrote:
> >
> > No way that this could cause corruption it is a read-only test.
>
> As others pointed out, it's probably something related to shared
> memory, but it's definitely hdparm that triggers it. I haven't
> got the hdparm sources here to look at what exactly it's doing,
> but there is corruption going on, not on disk, but definitely in
> memory.
>
> -Udo.
>
Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development
Followup to: <[email protected]>
By author: Andre Hedrick <[email protected]>
In newsgroup: linux.dev.kernel
>
> Did you set and mount a "/var/shm" point?
>
<HARP>
Please don't use the path /var/shm... it was a really bad precedent
set when someone suggested it. Use /dev/shm.
</HARP>
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
On 6 Dec 2000, H. Peter Anvin wrote:
> <HARP>
> Please don't use the path /var/shm... it was a really bad precedent
> set when someone suggested it. Use /dev/shm.
> </HARP>
And I'll ask again... If this is now the recommend mount point, can we
have devfs create this directory for us?
-Chris
--
Two penguins were walking on an iceburg. The first one said to the
second, "you look like you are wearing a tuxedo." The second one said,
"I might be..."
--David Lynch, Twin Peaks
Chris Meadors wrote:
>
> On 6 Dec 2000, H. Peter Anvin wrote:
>
> > <HARP>
> > Please don't use the path /var/shm... it was a really bad precedent
> > set when someone suggested it. Use /dev/shm.
> > </HARP>
>
> And I'll ask again... If this is now the recommend mount point, can we
> have devfs create this directory for us?
>
Richard?
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt