I am trying to bound corruption in a block-based disk format in the presence of plausible machine failures in a Linux-specific application. That is, the file is read and written in application-defined fixed-sized units at offsets which are multiples of that unit size essentially randomly.

I realise that a write to block n may or may not be corrupted if something terrible happens during the write, or before the write is synced: this is inevitable.

What I'd like to try to avoid is the possibility of this corrupting block n-1 or block n+1 if they are quiescent (no activity during the period).

Now if the block size is ridiculously small, 4 bytes say, then it's clear that block n will be, in various OS and hardware senses, "on the same page" as blocks n-1 and n+1 and that when the write of this page is in operation then some calamity might cause not only block n, but n-1,n+1,... to become corrupt (even if not changed?) on disk.

Is there some size at which I can set my blocks such that a write to block n is essentially independent of adjacent blocks in the sense that if one block is quiescent then a busy adjacent block could not cause it to become corrupt in the event of a non-byzantine failure?

Alignment issues can be dealt with by the insertion of padding if necessary, so that's not insurmountable.

Here are my thoughts so far: the commonly quoted 512-byte disk block seems unlikely as it's much too small, and I'm not sure if this even applies on modern disks and surely the OS memory write cache unit size is larger than that, anyway. I know that x86 page tables can be 4k (which sounds a sensible size) or 4M (which sounds too big). sysconf(_SC_PAGESIZE) returns a number, but is it the right one?

We can assume that my writes are to a non-daft filesystem type (ext-n or xfs, say) and that the machine is a standard 64-bit Linux x86 box, if any of that is relevant.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.