Perhaps I should clarify the question, I was thinking on journalising filesystems (ext3) on nonencrypted drives as well, eg. shouldn't _any_ ext3-user, also someone not using encryption, disable write-cache? Or is this case different because you have: ext3 | v loop | v physical driver, /dev/hda eg. an extra layer. In the end it comes down to finding the risk of just using write-cache anyway, with loop-aes and ext3, I mean, ext3 & write-cache disk are probably what most people use today, and it seems to me even in the write-cache enabled case, ext3 loses far less data than ext2. --- David <shadoweyez@xxxxxxxxx> skrev: > I'm no expert in this, but as I understand it, when using a system > like > loop-aes write cache _should_ be disabled, for the timing issue you > mentioned, so if you are using ext3 or reiser, disable write cache. > I > use ext2 for my loop-aes drive, and for most things I do, I do not > notice a difference in performance. > > Keysrub - I use it, but it's more of a sleep-well-at-night/bragging > thing anyway. Has anyone ever actually recovered an encryption key > or > password from looking at the oxidation layer that forms on a RAM > stick, > shortly after it has been in use? I have read parts of that paper, > but > trying to recover data like that seems far fetched at best. > > > petersen wrote: > > Dear Jari, > > > > In your README you write so: > > > > > > > > 2.2. Use of journaling file systems on loop device > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > ... 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). > > ---------------------------- > > > > > > To my understanding, the danger is that the filesystem terminates > an > > operation and updates the journal. The harddisk write cache > somehow > > manage to write the updated journal info, but when about to write > the > > filedata themselves, power is lost. > > > > Wouldn't that be a general problem with any journalised > filesystem? If > > so, as most OS'es nowadays have journalised filesystems, does the > modern > > harddisks have ways to prevent such problems, or does the > harddisk > > (filesystem?) driver implement some 'sync'-function before > commiting the > > journal? > > > > > > > > On another topic: shouldn't the KEYSCRUB option be enabled by > default? > > > > - > > Linux-crypto: cryptography in and on the Linux system > > Archive: http://mail.nl.linux.org/linux-crypto/ > > > > > . \ | / o O OO - (_) - ___ =========== =========== / | \ _U___|o| ... [ U U U U ] [ U U U U ] L______| [___] [_________] [_________] _______oo OOO__oo_oo__oo_____oo____oo_____oo_____ - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
