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: bstanoszek@comtime.com- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Dec 07 2000 - 21:00:15 EST