Re: Oopsing cryptoapi (or loop device?) on 2.6.*

[Jan Rychter <jan@rychter.com>]

[-- Attachment #1: Type: text/plain, Size: 2573 bytes --]

>>>>> "Jari" == Jari Ruusu <jariruusu@users.sourceforge.net>:
 Jari> Jan Rychter wrote:
 >> FWIW, I've just tried loop-AES with 2.4.24, after using cryptoapi
 >> for a number of years. My machine froze dead in the midst of copying
 >> 2.8GB of data onto my file-backed reiserfs encrypted loopback mount.
 >>
 >> Since the system didn't ever freeze on me before and since I've had
 >> zero problems with cryptoapi, I attribute the freeze to loop-AES.
 >>
 >> Yes, I know this isn't a good bugreport...

 Jari> Is there any particular reason why you insist on using file
 Jari> backed loops?

Yes. They are much easier to use from a practical standpoint. They do
not require repartitioning of your drives. They are easy to back up
using rsync. They are reasonably easy to resize (by creating another
file-backed loop side by side and copying the data).

Probably the biggest reason is that repartitioning laptop drives is a
difficult task. You can't just connect a second drive to a laptop, so
when you have a laptop that's full of data, there is no easy way to
repartition.

All in all, it's not a strict requirement, it's a convenience thing,
especially for those of us who do not sit in front of huge desktops,
where you can easily add and replace drives.

 Jari> File backed loops have hard to fix re-entry problem: GFP_NOFS
 Jari> memory allocations that cause dirty pages to written out to file
 Jari> backed loop, will have to re-enter the file system anyway to
 Jari> complete the write. This causes deadlocks. Same deadlocks are
 Jari> there in mainline loop+cryptoloop combo.

I have used cryptoapi (as modules) for the last 2 years (or so) now,
without encountering any problems whatsoever. I therefore beg to differ:
if the same deadlocks are there, then for some reason they are not
triggered on my machine. Two years versus an hour, that's a rather
significant difference in terms of reliability.

 Jari> This is one of the reasons why this is in loop-AES README: "If
 Jari> you can choose between device backed and file backed, choose
 Jari> device backed even if it means that you have to re-partition your
 Jari> disks."

I would humbly suggest that this annotation be made more explicit. Had
it said "DO NOT use file backed loop devices, as these do not work and
cause deadlocks", I would have never even tried loop-AES. As it stands,
I did, and it took about an hour to get a deadlock.

--J.  
PS: just as a clarification: my setup consists of reiserfs on top of an
encrypted file-backed loop device, the file sits on an ext3 fs mounted
with data=ordered.

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]