linux-ext4 - [Bug 16165] Wrong data returned on read after write if file size was changed with ftruncate before

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 16 Aug 2010 13:24:40 GMT
From:	bugzilla-daemon@...zilla.kernel.org
To:	linux-ext4@...r.kernel.org
Subject: [Bug 16165] Wrong data returned on read after write if file size was
 changed with ftruncate before

https://bugzilla.kernel.org/show_bug.cgi?id=16165

Michael Tokarev <mjt@....msk.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mjt@....msk.ru

--- Comment #23 from Michael Tokarev <mjt@....msk.ru>  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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html