Comment 31 for bug 204133

Revision history for this message
Colin Ian King (colin-king) wrote :

Agostino,

There is one more thing to consider and that is the sysctl's do not help with any pending blocks in the loopback device. There can be a substantial number of pending writes in the loopback block device which have yet to be pushed out to the filesystem. Thus there there are several points where unwritten data is vulnerable:

1. Blocks in the loopback device that have yet to be written to the filestore (pending block I/Os).
2. Blocks that have been written, but not yet flushed by pdflush to the underlying disk.
3. Blocks pending in the disk cache (in the drive itself) that have not been physcially written back.

Point 1 cannot be solved by sysctl style tweaks, and must be addressed in the loopback device. However, there is no provision for this in loop.c. It appears that the loop back threads are running at maximum priority, but there is some time lag between blocks being written to the loopback device and the blocks being pushed out by these worker threads.

Point 2 is address a little by sysctl tweaks, but there is still a few centisceconds worth of latency between blocks being written and the blocks actually being flushed to the device.

So, in the case of catastrophic power failure, the loop backed ext3 filesystem is evidently more vulnerable to file system corruption than the normal non-looped back filesystem.

Colin