On Wednesday 24 November 2010 12:00:20 Bob Lee wrote:
> Thanks, Charles!
>
> So, if we run out of available space, I'll get an error when I try to write
> to the hole? That should be OK... Very neat.
Yup the space is not reserved so you will run out. This is a down-side of
using sparse files or compressed files or anything that tries to be clever.
>
> I think I know what my real problem is. I write the expected file size to
> the file header. This enables me to recover from a failed queue expansion:
> https://github.com/square/retrofit/blob/master/modules/android/src/retrofit
>/io/QueueFile.java
>
> In the case I'm investigating, the header says 16k, but the file size is
> only 4k.
That could happen if there was a power failure before the metadata was
flushed.
If power is lost before the file size got synced then the file recovery
scanning would end up showing the file has 4k.
> I used "rwd" mode which syncs data by not metadata writes. In other words,
> it uses fdatasync() instead of fsync(). I think the file size qualifies as
> metadata. It sounds like my header write synced to storage but the file
> size metadata didn't, even though it was written first.
Correct. Bytes in file == data. Everything else is metadata.
>
> If I turn on metadata syncing, ftruncate() should sync, and everything
> should be OK.
>
> Sound plausible?
Sounds right to me.
-- Charles
(text/plain)