[SOLVED] Why are fdisk & df reporting different sizes for encrypted disk?

ItsTheSource · 10-19-2012, 08:41 PM

Here's the problem I'm having. I cannot determine slice size for dar, because I cannot figure out exactly what the slice size should be.

My output from fdisk -l seems to clash with my output from df. I didn't create any partitions when I encrypted the drive, so I believed that they should match. Alas, they do not.

Code:

# fdisk -l
Disk /dev/mapper/realcrypt1: 2000.4 GB, 2000398671872 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907028656 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

Code:

# df -B1
Filesystem                 1B-blocks          Used     Available Use% Mounted on
/dev/mapper/realcrypt1 1969009336320  435361845248 1533647491072  23% /mnt/esata

Obviously 2000398671872 bytes != 1969009336320 bytes. So what gives?

aetratus · 10-20-2012, 08:32 PM

fdisk looks at disks/partitions. df looks at filesystems. This seems to make sense on the face of it, since you encrypted the whole partition (which you referred to as a drive - it's not). The "extra" bytes fdisk sees are a function of the encryption and not useable - stick with what df reports.
FWIW, what does

Code:

tune2fs -l /dev/mapper/realcrypt1

show?

Wim Sturkenboom · 10-21-2012, 06:53 AM

Another possibility can be space allocated to the root user (5%).

rknichols · 10-21-2012, 10:00 AM

You are overlooking the file system overhead -- the space occupied by inodes, group descriptors, and the like. For an ext2/3/4 file system with the default parameters, this is around 1.5%. The report from df shows only the number of available data blocks after formatting.

ItsTheSource · 10-21-2012, 10:03 PM

Thanks for the information.