Skip to contentSkip to conversation

cryptsetup creates 1.8 Gb when it should be 1Tb

dm-crypt metageek 5 participants 9 messages Oct 28, 2013 – Oct 29, 2013

lore
Share & tools
lore

metageek

author
#0 lore raw

I've checked the FAQ, but this does not seem to be answered there...

I'm creating an encrypted partition on a portable USB3 drive. The drive is 1Tb and I've allocated all on a single partition:

Disk /dev/sdb: 1000.2 GB, 1000204885504 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525167 sectors Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x9f0bf2e1

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1              63  1953525166   976762552   83  Linux

Then I went on to create the LUKS encryption:

cryptsetup luksFormat /dev/sdb1

then open it:

cryptsetup luksOpen /dev/sdb1 pjhomecrypt

now using status to see its properties:

cryptsetup -v status pjhomecrypt
/dev/mapper/pjhomecrypt is active.
type: LUKS1
cipher: aes-cbc-essiv:sha256
keysize: 256 bits

  device:  /dev/loop0
  loop:    /dev/sdb1
  offset:  4096 sectors
  size:    3752880 sectors
  mode:    read/write

Command successful.

I see there are only 3752880 sectors at 512 bytes, this is only about 1.8 Gb!

creating an ext4 filesystem on this, and mounting it shows the same...:

mkfs.ext4 /dev/mapper/pjhomecrypt
mke2fs 1.42.6 (21-Sep-2012)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
117360 inodes, 469110 blocks
23455 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=482344960
15 block groups
32768 blocks per group, 32768 fragments per group
7824 inodes per group
Superblock backups stored on blocks:

        32768, 98304, 163840, 229376, 294912

Allocating group tables: done
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done mount /dev/mapper/pjhomecrypt /mnt
df -Th /mnt

Filesystem              Type  Size  Used Avail Use% Mounted on
/dev/mapper/pjhomecrypt ext4  1.8G  2.7M  1.7G   1% /mnt

So I only have 1.8Gb out of the 1Tb drive.
I've googled and can't find anyone with similar problems, so I must be missing something here, though I haven't figured it out.

Can anyone help here?

#1 lore raw

Looks like some bizarre bug to me. Or maybe you have a faked drive that actually is only 2GB? It has happened to some people in the past. Example:

http://www.thetechtip.com/the-fake-500gb-hard-drive-from-china/

In this case, maybe the device mapper does some check that the counterfitters have not anticipated and deduces a correct size.

Maybe post more info:
- What type of drive
- smartctl -i for that drive
- what kernel
- what cryptsetup version

Arno

Quoted 77 lines · metageek

I've checked the FAQ, but this does not seem to be answered there...

I'm creating an encrypted partition on a portable USB3 drive. The drive is 1Tb and I've allocated all on a single partition:

Disk /dev/sdb: 1000.2 GB, 1000204885504 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525167 sectors Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x9f0bf2e1

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1              63  1953525166   976762552   83  Linux

Then I went on to create the LUKS encryption:

cryptsetup luksFormat /dev/sdb1

then open it:

cryptsetup luksOpen /dev/sdb1 pjhomecrypt

now using status to see its properties:

cryptsetup -v status pjhomecrypt
/dev/mapper/pjhomecrypt is active.
type: LUKS1
cipher: aes-cbc-essiv:sha256
keysize: 256 bits

  device:  /dev/loop0
  loop:    /dev/sdb1
  offset:  4096 sectors
  size:    3752880 sectors
  mode:    read/write

Command successful.

I see there are only 3752880 sectors at 512 bytes, this is only about 1.8 Gb!

creating an ext4 filesystem on this, and mounting it shows the same...:

mkfs.ext4 /dev/mapper/pjhomecrypt
mke2fs 1.42.6 (21-Sep-2012)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
117360 inodes, 469110 blocks
23455 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=482344960
15 block groups
32768 blocks per group, 32768 fragments per group
7824 inodes per group
Superblock backups stored on blocks:

        32768, 98304, 163840, 229376, 294912

Allocating group tables: done
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done mount /dev/mapper/pjhomecrypt /mnt
df -Th /mnt

Filesystem              Type  Size  Used Avail Use% Mounted on
/dev/mapper/pjhomecrypt ext4  1.8G  2.7M  1.7G   1% /mnt

So I only have 1.8Gb out of the 1Tb drive.
I've googled and can't find anyone with similar problems, so I must be missing something here, though I haven't figured it out.

Can anyone help here?

_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt

Signature · 7 lines
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: [email protected]
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare
#2 lore raw
In reply to metageek
Quoted 1 line · metageek

Disk /dev/sdb: 1000.2 GB, 1000204885504 bytes

...

Quoted 3 lines

cryptsetup -v status pjhomecrypt
/dev/mapper/pjhomecrypt is active.
size: 3752880 sectors

...

Quoted 3 lines

mkfs.ext4 /dev/mapper/pjhomecrypt
Block size=4096 (log=2)
117360 inodes, 469110 blocks

...

Quoted 5 lines

df -Th /mnt

Filesystem              Type  Size  Used Avail Use% Mounted on
/dev/mapper/pjhomecrypt ext4  1.8G  2.7M  1.7G   1% /mnt

So I only have 1.8Gb out of the 1Tb drive.

What's the block count if you run:

dd if=/dev/zero of=/dev/sdb bs=1GB

It should be ~1000.

David

#3 lore raw
In reply to metageek

On 28.10.2013 3:05, metageek wrote:
...

Quoted 10 lines

Then I went on to create the LUKS encryption:

cryptsetup luksFormat /dev/sdb1

then open it:

cryptsetup luksOpen /dev/sdb1 pjhomecrypt

now using status to see its properties:

Quoted 8 lines

cryptsetup -v status pjhomecrypt
/dev/mapper/pjhomecrypt is active.
type: LUKS1
cipher: aes-cbc-essiv:sha256
keysize: 256 bits

device: /dev/loop0
loop: /dev/sdb1

^^^^ Why it is mapped through loop device?

Ensure that /dev/sdb1 is BLOCK device.

It seems to me that it is in fact just file created by mistake in /dev ... (Then limited by tmpfs size to half of memory or so and explains strange size.)

Also use lsblk to verify real kernel sizes
(sometimes kernel see old partition size)

Milan

author
#4 lore raw

Ok, problem solved now,

the last poster was spot on, for some reason that I cannot figure out, there was a regular file /dev/sdb1. After removing it (with the drive disconnected), everything works.

The drive is a Seagate Backup Plus portable drive

I'm running cryptsetup version 1.4.3 (the version in Slackware64 14.0, running kernel 3.8.8)

# dd if=/dev/zero of=/dev/sdb bs=1GB
dd: writing '/dev/sdb': No space left on device
1001+0 records in
1000+0 records out
1000204885504 bytes (1.0 TB) copied, 12064.5 s, 82.9 MB/s

so it is really 1.0 TB there (not a fake one)

#smartctl -i
/dev/sdb: Unknown USB bridge [0x0bc2:0xa013 (0x100)]

Now, status reports the full drive and no loopback:

# cryptsetup -v status pjhomecrypt
/dev/mapper/pjhomecrypt is active.
  type:    LUKS1
  cipher:  aes-cbc-essiv:sha256
  keysize: 256 bits
  device:  /dev/sdb1
  offset:  4096 sectors
  size:    1953521008 sectors
  mode:    read/write
Command successful.

The filesystem was created successfully with ~ 1 TB.

Problem solved.
Thanks everyone!

#5 lore raw

Interesting. This one was new for me.

Arno

Quoted 46 lines · metageek

Ok, problem solved now,

the last poster was spot on, for some reason that I cannot figure out, there was a regular file /dev/sdb1. After removing it (with the drive disconnected), everything works.

The drive is a Seagate Backup Plus portable drive

I'm running cryptsetup version 1.4.3 (the version in Slackware64 14.0, running kernel 3.8.8)

# dd if=/dev/zero of=/dev/sdb bs=1GB
dd: writing '/dev/sdb': No space left on device
1001+0 records in
1000+0 records out
1000204885504 bytes (1.0 TB) copied, 12064.5 s, 82.9 MB/s

so it is really 1.0 TB there (not a fake one)

#smartctl -i
/dev/sdb: Unknown USB bridge [0x0bc2:0xa013 (0x100)]

Now, status reports the full drive and no loopback:

# cryptsetup -v status pjhomecrypt
/dev/mapper/pjhomecrypt is active.
  type:    LUKS1
  cipher:  aes-cbc-essiv:sha256
  keysize: 256 bits
  device:  /dev/sdb1
  offset:  4096 sectors
  size:    1953521008 sectors
  mode:    read/write
Command successful.

The filesystem was created successfully with ~ 1 TB.

Problem solved.
Thanks everyone!

_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt

Signature · 7 lines
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: [email protected]
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare
#6 lore raw
Quoted 10 lines · Arno Wagner

Interesting. This one was new for me.

Arno

Quoted 5 lines · metageek

Ok, problem solved now,

the last poster was spot on, for some reason that I cannot figure out, there was a regular file /dev/sdb1. After removing it (with the drive disconnected), everything works.

I've seen it before in other contexts. Things can get really weird when there is an ordinary, non-empty file named /dev/null.

Signature · 2 lines
Bob Nichols     "NOSPAM" is really part of my email address.
                Do NOT delete it.
#7 lore raw
Quoted 6 lines · Robert Nichols
Quoted 5 lines · Arno Wagner

Interesting. This one was new for me.

Arno

On Mon, Oct 28, 2013 at 20:28:31 CET, metageek wrote:

Quoted 8 lines
Quoted 5 lines
Quoted 5 lines

Ok, problem solved now,

the last poster was spot on, for some reason that I cannot figure out, there was a regular file /dev/sdb1. After removing it (with the drive disconnected), everything works.

I've seen it before in other contexts. Things can get really weird when there is an ordinary, non-empty file named /dev/null.

Hehe, yes I can imagine that....

Arno

Quoted 9 lines
Signature · 8 lines
-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                Do NOT delete it.

_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Signature · 7 lines
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: [email protected]
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare
#8 lore raw
In reply to metageek
Quoted 3 lines · metageek

... for some reason that I cannot figure out, there was a regular file /dev/sdb1. After removing it (with the drive disconnected), everything works.

Sneaky. Likely, a finger-fumble (?). I find those laying around in strangest places. It can be fun to look inside with hexdump. :-)

David