From: bert hubert <ahu@ds9a.nl> Current bitkeeper features a cryptoloop which is not safe for journaled file systems and also a Device Mapper target which is. The patch below updates Kconfig to that effect. --- drivers/block/Kconfig | 16 ++++++++++++---- 1 files changed, 12 insertions(+), 4 deletions(-) diff -puN drivers/block/Kconfig~dm-crypt-cryptoloop-docco drivers/block/Kconfig --- 25/drivers/block/Kconfig~dm-crypt-cryptoloop-docco 2004-02-19 23:25:53.000000000 -0800 +++ 25-akpm/drivers/block/Kconfig 2004-02-19 23:25:53.000000000 -0800 @@ -235,10 +235,13 @@ config BLK_DEV_LOOP bits of, say, a sound file). This is also safe if the file resides on a remote file server. - There are several ways of doing this. Some of these require kernel - patches. The vanilla kernel offers the cryptoloop option. If you - want to use that, say Y to both LOOP and CRYPTOLOOP, and make sure - you have a recent (version 2.12 or later) version of util-linux. + There are several ways of encrypting disks. Some of these require + kernel patches. The vanilla kernel offers the cryptoloop option + and a Device Mapper target (which is superior, as it supports all + file systems). If you want to use the cryptoloop, say Y to both + LOOP and CRYPTOLOOP, and make sure you have a recent (version 2.12 + or later) version of util-linux. Additionally, be aware that + the cryptoloop is not safe for storing journaled filesystems. Note that this loop device has nothing to do with the loopback device used for network connections from the machine to itself. @@ -257,6 +260,11 @@ config BLK_DEV_CRYPTOLOOP provided by the CryptoAPI as loop transformation. This might be used as hard disk encryption. + WARNING: This device is not safe for journaled file systems like + ext3 or Reiserfs. Please use the Device Mapper crypto module + instead, which can be configured to be on-disk compatible with the + cryptoloop device. + config BLK_DEV_NBD tristate "Network block device support" depends on NET _