Re: 2.6.1 CryptoAPI woes
On Wed, Jan 21, 2004 at 05:12:18AM -0400, Peter Cordes wrote: > On Tue, Jan 20, 2004 at 11:07:51PM -0800, Johannes Graumann wrote: > > I feel this is kind of over my head ... to boil it down: does it even > > make sense to run reiserfs inside a loopback partition? > > Yes, if the file you're looping back to is on a journalled filesystem, or > is a partition. Does keeping the log off the loopbacked file make any difference? bit, adam -- Am I a cleric? | 1024D/37B8D989 Or maybe a sinner? | 954B 998A E5F5 BA2A 3622 Unbeliever?| 82DD 54C2 843D 37B8 D989 Renegade? | http://sks.dnsalias.net
Re: 2.6.1 CryptoAPI woes
On Wed, Jan 21, 2004 at 05:12:18AM -0400, Peter Cordes wrote: > On Tue, Jan 20, 2004 at 11:07:51PM -0800, Johannes Graumann wrote: > > I feel this is kind of over my head ... to boil it down: does it even > > make sense to run reiserfs inside a loopback partition? > > Yes, if the file you're looping back to is on a journalled filesystem, or > is a partition. Does keeping the log off the loopbacked file make any difference? bit, adam -- Am I a cleric? | 1024D/37B8D989 Or maybe a sinner? | 954B 998A E5F5 BA2A 3622 Unbeliever?| 82DD 54C2 843D 37B8 D989 Renegade? | http://sks.dnsalias.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.1 CryptoAPI woes
On Wed, 21 Jan 2004 05:12:18 -0400 Peter Cordes <[EMAIL PROTECTED]> wrote: > On Tue, Jan 20, 2004 at 11:07:51PM -0800, Johannes Graumann wrote: > > I feel this is kind of over my head ... to boil it down: does it > > even make sense to run reiserfs inside a loopback partition? > > Yes, if the file you're looping back to is on a journalled > filesystem, or > is a partition. > > (ext3 is fine, but you need to patch reiserfs for ordered data.) OK, I'm using a partition - will stick with ext3 for now to circumvent patching. I'm sufficiently fighting with the swsuspend2 patch ;0) Thanks! Joh
Re: 2.6.1 CryptoAPI woes
On Wed, 21 Jan 2004 05:12:18 -0400 Peter Cordes <[EMAIL PROTECTED]> wrote: > On Tue, Jan 20, 2004 at 11:07:51PM -0800, Johannes Graumann wrote: > > I feel this is kind of over my head ... to boil it down: does it > > even make sense to run reiserfs inside a loopback partition? > > Yes, if the file you're looping back to is on a journalled > filesystem, or > is a partition. > > (ext3 is fine, but you need to patch reiserfs for ordered data.) OK, I'm using a partition - will stick with ext3 for now to circumvent patching. I'm sufficiently fighting with the swsuspend2 patch ;0) Thanks! Joh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.1 CryptoAPI woes
On Tue, Jan 20, 2004 at 11:07:51PM -0800, Johannes Graumann wrote: > I feel this is kind of over my head ... to boil it down: does it even > make sense to run reiserfs inside a loopback partition? Yes, if the file you're looping back to is on a journalled filesystem, or is a partition. (ext3 is fine, but you need to patch reiserfs for ordered data.) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC signature.asc Description: Digital signature
Re: 2.6.1 CryptoAPI woes
On Tue, Jan 20, 2004 at 11:07:51PM -0800, Johannes Graumann wrote: > I feel this is kind of over my head ... to boil it down: does it even > make sense to run reiserfs inside a loopback partition? Yes, if the file you're looping back to is on a journalled filesystem, or is a partition. (ext3 is fine, but you need to patch reiserfs for ordered data.) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC signature.asc Description: Digital signature
Re: 2.6.1 CryptoAPI woes
I feel this is kind of over my head ... to boil it down: does it even make sense to run reiserfs inside a loopback partition? Thanks, Joh On Wed, 21 Jan 2004 01:34:25 -0400 Peter Cordes <[EMAIL PROTECTED]> wrote: > On Tue, Jan 20, 2004 at 11:58:41PM -0500, Hubert Chan wrote: > > > "Johannes" == Johannes Graumann <[EMAIL PROTECTED]> writes: > > > > [...] > > > > Johannes> And on another note: in > > Johannes> > > http://www.mirrors.wiretapped.net/security/cryptography/filesystems/loop-aes/loop-AES.README > > Johannes> I read the following: "Don't use a journaling file system > > on Johannes> top of file backed loop device, unless underlying file > > system Johannes> is journaled and guarantees data=ordered or > > data=journal." Johannes> Can anybody comment on whether I can use > > reiserfs on top of my Johannes> loopback? > > > > The comment has nothing to do with whether or not your encrypted > > filesystem is a journaling filesystem with or without data=ordered. > > Actually, it does. > > > It > > has to do with using a file-backed loop device (versus > > partition-backed loop device), where the file is sitting on a > > journaling filesystem. If your loop device is a partition, or is > > file-based, but sits on top of a non-journaled filesystem > > Wait a second; I think this one doesn't belong in the list of things > that > will be correct. > > > or a journaled filesystem with data=ordered or > > journaled, then you can use any filesystem without problems. (Or, > > at least, you won't (shouldn't) run into any problems other than > > what you might run into if it were not on a loopback device.) > > > > Basically, if you don't have data=ordered, or data=journaled, any > > system crash could completely screw up your entire loopback, > > rendering it completely unusable. If you don't plan on having any > > system crashes or hard reboots, I think you can still run a loopback > > on top a non-data=ordered journaled filesystem fairly safely. > > No, the point is that journaling file systems depend on stuff being > written > to disk in the order they want, so if something goes wrong at _any_ > moment, they can pick up the pieces. ext3 with data=writeback, for > example, only bothers to strictly control the order of metadata. A > loopback to a file on such a filesystem will not preserve write > ordering, so a journaling filesystem on top of it will be making false > assumptions. Filesystem metadata (which needs to be ordered) is just > data on the loopback device. However, if the underlying filesystem > preserves data ordering, it can satisfy the requirements of the > journaling filesystem that's on top of it. > > I'm not sure if you need data=journal on the underlying filesystem > for > data=journal on the loopback filesystem to make sense, but I don't > think so. > > -- > #define X(x,y) x##y > Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) > > "The gods confound the man who first found out how to distinguish the > hours! > Confound him, too, who in this place set up a sundial, to cut and > hack my day so wretchedly into small pieces!" -- Plautus, 200 BC >
Re: 2.6.1 CryptoAPI woes
I feel this is kind of over my head ... to boil it down: does it even make sense to run reiserfs inside a loopback partition? Thanks, Joh On Wed, 21 Jan 2004 01:34:25 -0400 Peter Cordes <[EMAIL PROTECTED]> wrote: > On Tue, Jan 20, 2004 at 11:58:41PM -0500, Hubert Chan wrote: > > > "Johannes" == Johannes Graumann <[EMAIL PROTECTED]> writes: > > > > [...] > > > > Johannes> And on another note: in > > Johannes> > > http://www.mirrors.wiretapped.net/security/cryptography/filesystems/loop-aes/loop-AES.README > > Johannes> I read the following: "Don't use a journaling file system > > on Johannes> top of file backed loop device, unless underlying file > > system Johannes> is journaled and guarantees data=ordered or > > data=journal." Johannes> Can anybody comment on whether I can use > > reiserfs on top of my Johannes> loopback? > > > > The comment has nothing to do with whether or not your encrypted > > filesystem is a journaling filesystem with or without data=ordered. > > Actually, it does. > > > It > > has to do with using a file-backed loop device (versus > > partition-backed loop device), where the file is sitting on a > > journaling filesystem. If your loop device is a partition, or is > > file-based, but sits on top of a non-journaled filesystem > > Wait a second; I think this one doesn't belong in the list of things > that > will be correct. > > > or a journaled filesystem with data=ordered or > > journaled, then you can use any filesystem without problems. (Or, > > at least, you won't (shouldn't) run into any problems other than > > what you might run into if it were not on a loopback device.) > > > > Basically, if you don't have data=ordered, or data=journaled, any > > system crash could completely screw up your entire loopback, > > rendering it completely unusable. If you don't plan on having any > > system crashes or hard reboots, I think you can still run a loopback > > on top a non-data=ordered journaled filesystem fairly safely. > > No, the point is that journaling file systems depend on stuff being > written > to disk in the order they want, so if something goes wrong at _any_ > moment, they can pick up the pieces. ext3 with data=writeback, for > example, only bothers to strictly control the order of metadata. A > loopback to a file on such a filesystem will not preserve write > ordering, so a journaling filesystem on top of it will be making false > assumptions. Filesystem metadata (which needs to be ordered) is just > data on the loopback device. However, if the underlying filesystem > preserves data ordering, it can satisfy the requirements of the > journaling filesystem that's on top of it. > > I'm not sure if you need data=journal on the underlying filesystem > for > data=journal on the loopback filesystem to make sense, but I don't > think so. > > -- > #define X(x,y) x##y > Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) > > "The gods confound the man who first found out how to distinguish the > hours! > Confound him, too, who in this place set up a sundial, to cut and > hack my day so wretchedly into small pieces!" -- Plautus, 200 BC > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.1 CryptoAPI woes
On Tue, Jan 20, 2004 at 11:58:41PM -0500, Hubert Chan wrote: > > "Johannes" == Johannes Graumann <[EMAIL PROTECTED]> writes: > > [...] > > Johannes> And on another note: in > Johannes> > http://www.mirrors.wiretapped.net/security/cryptography/filesystems/loop-aes/loop-AES.README > Johannes> I read the following: "Don't use a journaling file system on > Johannes> top of file backed loop device, unless underlying file system > Johannes> is journaled and guarantees data=ordered or data=journal." > Johannes> Can anybody comment on whether I can use reiserfs on top of my > Johannes> loopback? > > The comment has nothing to do with whether or not your encrypted > filesystem is a journaling filesystem with or without data=ordered. Actually, it does. > It > has to do with using a file-backed loop device (versus partition-backed > loop device), where the file is sitting on a journaling filesystem. If > your loop device is a partition, or is file-based, but sits on top of a > non-journaled filesystem Wait a second; I think this one doesn't belong in the list of things that will be correct. > or a journaled filesystem with data=ordered or > journaled, then you can use any filesystem without problems. (Or, at > least, you won't (shouldn't) run into any problems other than what you > might run into if it were not on a loopback device.) > > Basically, if you don't have data=ordered, or data=journaled, any system > crash could completely screw up your entire loopback, rendering it > completely unusable. If you don't plan on having any system crashes or > hard reboots, I think you can still run a loopback on top a > non-data=ordered journaled filesystem fairly safely. No, the point is that journaling file systems depend on stuff being written to disk in the order they want, so if something goes wrong at _any_ moment, they can pick up the pieces. ext3 with data=writeback, for example, only bothers to strictly control the order of metadata. A loopback to a file on such a filesystem will not preserve write ordering, so a journaling filesystem on top of it will be making false assumptions. Filesystem metadata (which needs to be ordered) is just data on the loopback device. However, if the underlying filesystem preserves data ordering, it can satisfy the requirements of the journaling filesystem that's on top of it. I'm not sure if you need data=journal on the underlying filesystem for data=journal on the loopback filesystem to make sense, but I don't think so. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC signature.asc Description: Digital signature
Re: 2.6.1 CryptoAPI woes
> "Hubert" == Hubert Chan <[EMAIL PROTECTED]> writes: replying to self... [...] Hubert> The comment has nothing to do with whether or not your encrypted Hubert> filesystem is a journaling filesystem with or without Hubert> data=ordered. ... Hmmm. Maybe I should learn to read... :-( So that comment was about using a journaling filesystem on a loopback that sits on a journaling system. But AFAICT, using a loopback that sits on a journaling system that does not have data=ordered, or data=journal is not a very good idea. The corruption that I had mentioned before is still possible. As well, filesystems generally have to make some sort of assumptions that, "if I had asked data A to be written to the disk before data B, then if B has been written, then A should also have been written." I don't think you get that on your loopback unless you have data=ordered or data=journal. Perhaps journaling filesystems are more dependent on that assumption. Anyways, my previous comment on needing Chris Mason's patches to get data=ordered and data=journal on reiserfs still stands, of course. -- Hubert Chan <[EMAIL PROTECTED]> - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. pgpwM80is6Efn.pgp Description: PGP signature
Re: 2.6.1 CryptoAPI woes
> "Johannes" == Johannes Graumann <[EMAIL PROTECTED]> writes: [...] Johannes> And on another note: in Johannes> http://www.mirrors.wiretapped.net/security/cryptography/filesystems/loop-aes/loop-AES.README Johannes> I read the following: "Don't use a journaling file system on Johannes> top of file backed loop device, unless underlying file system Johannes> is journaled and guarantees data=ordered or data=journal." Johannes> Can anybody comment on whether I can use reiserfs on top of my Johannes> loopback? The comment has nothing to do with whether or not your encrypted filesystem is a journaling filesystem with or without data=ordered. It has to do with using a file-backed loop device (versus partition-backed loop device), where the file is sitting on a journaling filesystem. If your loop device is a partition, or is file-based, but sits on top of a non-journaled filesystem or a journaled filesystem with data=ordered or journaled, then you can use any filesystem without problems. (Or, at least, you won't (shouldn't) run into any problems other than what you might run into if it were not on a loopback device.) Basically, if you don't have data=ordered, or data=journaled, any system crash could completely screw up your entire loopback, rendering it completely unusable. If you don't plan on having any system crashes or hard reboots, I think you can still run a loopback on top a non-data=ordered journaled filesystem fairly safely. reiserfs does not have data=ordered or data=journal semantics by default. In order to get this, you must apply Chris Mason's patch, and recompile the kernel. ftp://ftp.suse.com/pub/people/mason/patches/data-logging/2.4.20/ and select your kernel version. Apply the patches in order. (Patches for 2.6.x are currently experimental.) These patches should get merged into mainline sometime ... soon. (For some value of "soon".) You'll also have to add a "data=ordered" or "data=journal" mount option. (data=ordered will be the default in some future version.) -- Hubert Chan <[EMAIL PROTECTED]> - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. pgproTH7FPVBx.pgp Description: PGP signature
Re: 2.6.1 CryptoAPI woes
On Tue, Jan 20, 2004 at 11:58:41PM -0500, Hubert Chan wrote: > > "Johannes" == Johannes Graumann <[EMAIL PROTECTED]> writes: > > [...] > > Johannes> And on another note: in > Johannes> > http://www.mirrors.wiretapped.net/security/cryptography/filesystems/loop-aes/loop-AES.README > Johannes> I read the following: "Don't use a journaling file system on > Johannes> top of file backed loop device, unless underlying file system > Johannes> is journaled and guarantees data=ordered or data=journal." > Johannes> Can anybody comment on whether I can use reiserfs on top of my > Johannes> loopback? > > The comment has nothing to do with whether or not your encrypted > filesystem is a journaling filesystem with or without data=ordered. Actually, it does. > It > has to do with using a file-backed loop device (versus partition-backed > loop device), where the file is sitting on a journaling filesystem. If > your loop device is a partition, or is file-based, but sits on top of a > non-journaled filesystem Wait a second; I think this one doesn't belong in the list of things that will be correct. > or a journaled filesystem with data=ordered or > journaled, then you can use any filesystem without problems. (Or, at > least, you won't (shouldn't) run into any problems other than what you > might run into if it were not on a loopback device.) > > Basically, if you don't have data=ordered, or data=journaled, any system > crash could completely screw up your entire loopback, rendering it > completely unusable. If you don't plan on having any system crashes or > hard reboots, I think you can still run a loopback on top a > non-data=ordered journaled filesystem fairly safely. No, the point is that journaling file systems depend on stuff being written to disk in the order they want, so if something goes wrong at _any_ moment, they can pick up the pieces. ext3 with data=writeback, for example, only bothers to strictly control the order of metadata. A loopback to a file on such a filesystem will not preserve write ordering, so a journaling filesystem on top of it will be making false assumptions. Filesystem metadata (which needs to be ordered) is just data on the loopback device. However, if the underlying filesystem preserves data ordering, it can satisfy the requirements of the journaling filesystem that's on top of it. I'm not sure if you need data=journal on the underlying filesystem for data=journal on the loopback filesystem to make sense, but I don't think so. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC signature.asc Description: Digital signature
Re: 2.6.1 CryptoAPI woes
> "Hubert" == Hubert Chan <[EMAIL PROTECTED]> writes: replying to self... [...] Hubert> The comment has nothing to do with whether or not your encrypted Hubert> filesystem is a journaling filesystem with or without Hubert> data=ordered. ... Hmmm. Maybe I should learn to read... :-( So that comment was about using a journaling filesystem on a loopback that sits on a journaling system. But AFAICT, using a loopback that sits on a journaling system that does not have data=ordered, or data=journal is not a very good idea. The corruption that I had mentioned before is still possible. As well, filesystems generally have to make some sort of assumptions that, "if I had asked data A to be written to the disk before data B, then if B has been written, then A should also have been written." I don't think you get that on your loopback unless you have data=ordered or data=journal. Perhaps journaling filesystems are more dependent on that assumption. Anyways, my previous comment on needing Chris Mason's patches to get data=ordered and data=journal on reiserfs still stands, of course. -- Hubert Chan <[EMAIL PROTECTED]> - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. pgp0.pgp Description: PGP signature
Re: 2.6.1 CryptoAPI woes
> "Johannes" == Johannes Graumann <[EMAIL PROTECTED]> writes: [...] Johannes> And on another note: in Johannes> http://www.mirrors.wiretapped.net/security/cryptography/filesystems/loop-aes/loop-AES.README Johannes> I read the following: "Don't use a journaling file system on Johannes> top of file backed loop device, unless underlying file system Johannes> is journaled and guarantees data=ordered or data=journal." Johannes> Can anybody comment on whether I can use reiserfs on top of my Johannes> loopback? The comment has nothing to do with whether or not your encrypted filesystem is a journaling filesystem with or without data=ordered. It has to do with using a file-backed loop device (versus partition-backed loop device), where the file is sitting on a journaling filesystem. If your loop device is a partition, or is file-based, but sits on top of a non-journaled filesystem or a journaled filesystem with data=ordered or journaled, then you can use any filesystem without problems. (Or, at least, you won't (shouldn't) run into any problems other than what you might run into if it were not on a loopback device.) Basically, if you don't have data=ordered, or data=journaled, any system crash could completely screw up your entire loopback, rendering it completely unusable. If you don't plan on having any system crashes or hard reboots, I think you can still run a loopback on top a non-data=ordered journaled filesystem fairly safely. reiserfs does not have data=ordered or data=journal semantics by default. In order to get this, you must apply Chris Mason's patch, and recompile the kernel. ftp://ftp.suse.com/pub/people/mason/patches/data-logging/2.4.20/ and select your kernel version. Apply the patches in order. (Patches for 2.6.x are currently experimental.) These patches should get merged into mainline sometime ... soon. (For some value of "soon".) You'll also have to add a "data=ordered" or "data=journal" mount option. (data=ordered will be the default in some future version.) -- Hubert Chan <[EMAIL PROTECTED]> - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. pgp0.pgp Description: PGP signature
Re: 2.6.1 CryptoAPI woes
On Tue, Jan 20, 2004 at 08:47:40AM -0800, Johannes Graumann wrote: > Now: how do I make sure this is AES-256 and not some other permutation > of the cypher? You use the losetup -k (or --keybits) option. Eg. losetup -e aes -k 256 ... /Thomas -- == [EMAIL PROTECTED] | [EMAIL PROTECTED] == Encrypted e-mails preferred | GPG KeyID: 114AA85C -- signature.asc Description: Digital signature
Re: 2.6.1 CryptoAPI woes
On Tue, Jan 20, 2004 at 08:47:40AM -0800, Johannes Graumann wrote: > "Don't use a journaling file system on top of file backed loop device, > unless underlying file system is journaled and guarantees data=ordered > or data=journal." AFAIK, This reads as: ``Don't think journalling buys you anything, unless the lower layers actually write the journalling data to the disk.'' If you have a journalling fs (A) over a non-journalled fs (B), on a crash you'll get A thinking it's journal/whatever is reliable, while B crashed without writing A's journal to the disk. The result will likely be the A more corrupted than it would be without the journalling turned on. HTH, Jan. -- Jan Minar "Please don't CC me, I'm subscribed." x 9 pgpQefBoYnNKx.pgp Description: PGP signature
2.6.1 CryptoAPI woes
Hello, I set out to create an encrypted partition using my new 2.6.1 custom kernel (compiled from kernel.org sources, loopdevice and cryptoloop statically compiled in, ciphers present as modules). Following what was said in several HOWTOs, I said 'modprobe aes' and tried various permutations of 'losetup -e aes-256 /dev/loop0 /dev/hda4' - with the result that I went nearly mad running into 'ioctl: LOOP_SET_STATUS: Invalid argument' after entering the password. After several hours I was about to accept defeat, when I used 'losetup -e aes /dev/loop0 /dev/hda4' - and behold: it works! Now: how do I make sure this is AES-256 and not some other permutation of the cypher? And on another note: in http://www.mirrors.wiretapped.net/security/cryptography/filesystems/loop-aes/loop-AES.README I read the following: "Don't use a journaling file system on top of file backed loop device, unless underlying file system is journaled and guarantees data=ordered or data=journal." Can anybody comment on whether I can use reiserfs on top of my loopback? Thanks for any hints, Joh
Re: 2.6.1 CryptoAPI woes
On Tue, Jan 20, 2004 at 08:47:40AM -0800, Johannes Graumann wrote: > Now: how do I make sure this is AES-256 and not some other permutation > of the cypher? You use the losetup -k (or --keybits) option. Eg. losetup -e aes -k 256 ... /Thomas -- == [EMAIL PROTECTED] | [EMAIL PROTECTED] == Encrypted e-mails preferred | GPG KeyID: 114AA85C -- signature.asc Description: Digital signature
Re: 2.6.1 CryptoAPI woes
On Tue, Jan 20, 2004 at 08:47:40AM -0800, Johannes Graumann wrote: > "Don't use a journaling file system on top of file backed loop device, > unless underlying file system is journaled and guarantees data=ordered > or data=journal." AFAIK, This reads as: ``Don't think journalling buys you anything, unless the lower layers actually write the journalling data to the disk.'' If you have a journalling fs (A) over a non-journalled fs (B), on a crash you'll get A thinking it's journal/whatever is reliable, while B crashed without writing A's journal to the disk. The result will likely be the A more corrupted than it would be without the journalling turned on. HTH, Jan. -- Jan Minar "Please don't CC me, I'm subscribed." x 9 pgp0.pgp Description: PGP signature
2.6.1 CryptoAPI woes
Hello, I set out to create an encrypted partition using my new 2.6.1 custom kernel (compiled from kernel.org sources, loopdevice and cryptoloop statically compiled in, ciphers present as modules). Following what was said in several HOWTOs, I said 'modprobe aes' and tried various permutations of 'losetup -e aes-256 /dev/loop0 /dev/hda4' - with the result that I went nearly mad running into 'ioctl: LOOP_SET_STATUS: Invalid argument' after entering the password. After several hours I was about to accept defeat, when I used 'losetup -e aes /dev/loop0 /dev/hda4' - and behold: it works! Now: how do I make sure this is AES-256 and not some other permutation of the cypher? And on another note: in http://www.mirrors.wiretapped.net/security/cryptography/filesystems/loop-aes/loop-AES.README I read the following: "Don't use a journaling file system on top of file backed loop device, unless underlying file system is journaled and guarantees data=ordered or data=journal." Can anybody comment on whether I can use reiserfs on top of my loopback? Thanks for any hints, Joh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
