As observed in bug 741808, fallocate doesn't work correctly on Android for small files. The problem is the following logic in mozilla::fallocate: int64_t iWrite = ((buf.st_size + 2 * nBlk - 1) / nBlk) * nBlk - 1; // Next offset to write to do { nWrite = 0; if (PR_Seek64(aFD, iWrite, PR_SEEK_SET) == iWrite) nWrite = PR_Write(aFD, "", 1); iWrite += nBlk; } while (nWrite == 1 && iWrite < aLength); Because of the do {} while loop we will always write at least one extra block to the file. This means it would also be broken for large files that are extended by less than a filesystem block. The code purports to be copied from sqlite, but the sqlite source in our tree does do it correctly: iWrite = ((buf.st_size + 2*nBlk - 1)/nBlk)*nBlk-1; while( iWrite<nSize ){ int nWrite = seekAndWrite(pFile, iWrite, "", 1); if( nWrite!=1 ) return SQLITE_IOERR_WRITE; iWrite += nBlk; }

Comment on attachment 661283 [details] [diff] [review] Patch 1. Fix broken fallocate logic Good catch. Oops. Shouldn't have copied this blindly. While we should fix this, the proper fix here is to implement the fallocate syscall on android. I'm starting to question the value of this fallback path. A crappy filesystem will still fragment under the emulated fallocate, but this fallback costs us non-constant io(whereas fallocate has a constant io cost). We should change fallocate to try_to_fallocate to make it more of an advisory call that does not execute fallback paths(other than a single sparse write to get a consistent file size).

https://tbpl.mozilla.org/?tree=Try&rev=8b8880b38702 >While we should fix this, the proper fix here is to implement the fallocate >syscall on android. Bug 693485. >I'm starting to question the value of this fallback path. It probably works reasonably well on Android, which has a crappy libc but in most cases should have a reasonably filesystem. For our other core platforms we have working fallocate code.