https://bugzilla.kernel.org/show_bug.cgi?id=16165 Michael Tokarev <mjt@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mjt@xxxxxxxxxx --- Comment #23 from Michael Tokarev <mjt@xxxxxxxxxx> 2010-08-16 13:24:32 --- Yesterday I observed another data corruption that looks very close to this one, but slightly different (and much more serious). The scenario is this: oracle10 database, creating db and importing data. Oracle uses ftruncate() to create file of a desired size, next it fills the file with block headers, so there's no unwritten data in the file. So far so good. There's also temporary tablespaces, which aren't filled during creation, but just ftruncate'd. The problem here happens when I extend a temp file during heavy database writes. It were needed a few times because in order to create large indexes, large temporary space were needed. And each time I try extend temp file (say, from 10 to 20Gb), oracle performs the ftruncate on it, and continues writing to it and to other data files (which were pre-filled after ftruncate, even before system restart). And during this time, there's a very likely chance to have _other_ data files to be corrupt while it is writing to the newly extended temp space. We observed several chunks of zeros (of size 1Mb each) written over _other_ files during this time. Re-read of those other files returns the same zeros. So, this delayed allocation corrupts _other_ data files which are already allocated and written. Avoiding gaps eliminates the problem. Note that oracle uses aio and direct-io and "gapful" files at least for the temporary ts. The kernel in question is 2.6.32.15. This is quite a major issue... But I repeat: i'm not sure it's related to this bugreport. At least the roots are somewhere very close. BTW, when it started in XFS, anyone know? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. -- 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
