Well, not quite. I think it is variable. In order to get it on my box: # cryptsetup luksDump /dev/sdb1|grep 'Payload offset' Payload offset: 1032 Which is the same as what we'd expect from the /dev sizes. # blockdev --getsize /dev/sdb1 488392002 # blockdev --getsize /dev/mapper/chome 488390970 All this is measured in sectors. To get something in bytes, multiply by the following number: # blockdev --getss /dev/sdb1 512 -- Roscoe On 7/6/07, Raphaël Gertz <rapsys@xxxxxxx> wrote:
Le Tuesday 03 July 2007 10:57:14 Nelson Batalha, vous avez écrit: > Hi, > > I would like to know how much space Luks takes in the encryp. volume. > That is, I would like to estimate, based on the device space and key > size, an upper estimative. > > > Why? Read on: > > I'm adding Gentoo Catalyst the ability to encrypt livecd's. The patches > are functional and practically finished: > > http://mega.ist.utl.pt/~nhqb/gentoo/catalyst/catalyst_luks_02.patch > http://mega.ist.utl.pt/~nhqb/gentoo/catalyst/genkernel_luks_cd2.patch > > but I'm using a very rough estimate: the cd's loop image (the thing I'm > encrypting) usually takes at most 630 megas, now I'm adding 2930*512 > bytes, not enough for livedvd's for instance, and too much for minicd's. > > BTW the luks performance, even for livecd's, is really good, thanks! > > Cheers, > Nelson > luks will not take more space than normal. luks just use a header of 512k last time i checked. (and 512k more at end if backup of luks header has been added there as suggested a while ago). Then it depend on the iso size and type. If you use a compressed filesystem you will need to compress before encrypt, because encrypted result should have a worse compression ratio. Except that, you will need the modules, the userland tool. I don't think the userland tool will take many space...
--------------------------------------------------------------------- dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx
