The loop-AES README says that
Device backed loop device can be used with journaling file systems as device backed loops guarantee that writes reach disk platters in order required by journaling file system (write caching must be disabled on the disk drive, of course). With file backed loop devices, correct write ordering may extend only to page cache (which resides in RAM) of underlying file system. VM can write such pages to disk in any order it wishes, and thus break write order expectation of journaling file system.
Could someone explain why caching is even an issue?
I'm familiar with the Solaris kernel but not the Linux kernel, but
by analogy I would imagine that the VM's page cache is completely
transparent to any layer above it. Thus a read following a given combination of writes will always return the same data regardless of whether the device is backed by a page-layer or not. The same must
surely be true of a write-caching disk drive. It is true that at a
given point in time, there will be no one single location (e.g.
disk platters, disk cache or VM page layer) containing a
contiguous representation of the data. However, I would have thought
that this would be an issue only if there was a sudden power failure.
Any thoughts would be gratefully received.
Regards,
Jim
_________________________________________________________________
Find a cheaper internet access deal - choose one to suit you. http://www.msn.co.uk/internetaccess
- Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
