In short, why does "df" show a total size different then what I created with lvcreate ? I guess that some overhead is needed for the fs houskeeping but why loose both outside and inside the fs? Example of what I mean: root@enterprise:~# lvcreate -L50G -ntest vg1 Logical volume "test" created root@enterprise:~# lvdisplay /dev/vg1/test ... LV Size 50.00 GB Current LE 12800 # =51200MiB/4MiB ... root@enterprise:~# mkfs.ext3 -m0 /dev/vg1/test ... root@enterprise:~# tune2fs -l /dev/vg1/test tune2fs 1.40.2 (12-Jul-2007) Filesystem volume name: <none> Last mounted on: <not available> Filesystem UUID: eace2e9a-6d63-4618-a1fd-60461a5e7bc9 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal resize_inode dir_index filetype sparse_super large_file Filesystem flags: signed directory hash Default mount options: (none) Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 6553600 Block count: 13107200 Reserved block count: 0 Free blocks: 12855467 Free inodes: 6553589 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 1020 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 16384 Inode blocks per group: 512 Filesystem created: Sat Feb 9 13:06:47 2008 Last mount time: n/a Last write time: Sat Feb 9 13:07:08 2008 Mount count: 0 Maximum mount count: 26 Last checked: Sat Feb 9 13:06:47 2008 Check interval: 15552000 (6 months) Next check after: Thu Aug 7 14:06:47 2008 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 128 Journal inode: 8 Default directory hash: tea Directory Hash Seed: c983ba00-c00f-45e7-a7af-d1570736a650 Journal backup: inode blocks Root reserved=0 so you can remove that common answer from the list of suspects. Here we have 13107200 blocks or 13107200*4096/1024/1024=51200MiByte, still on track more or less. Free blocks is 12855467 (50216 MiB) so we already lost (13107200-12855467)*4096/1024/1024=983 MiByte or ~1.9% to houskeeping I assume. root@enterprise:~# mount /dev/vg1/test /tmp/test root@enterprise:~# df -k /tmp/test Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/vg1-test 51606140 184272 51421868 1% /tmp/test Hmm, 51606140/1024=50396 MiB total size but tune2fs said 51200MiB total size so what happened to 804MiB ? 179MiB used (of which the journal is 128MiB) but at least free space is same as tune2fs stated (50216 MiB) so it dropped some outside the total size and some is inside the fs as used part. The issue of course grows with size, I first noticed this when a customer asked for a 900GiB fs and I did lvcreate -L900G but ended up with a lot less in the total part reported by "df" (and the customer almost questioned my competency) and had to grow the fs a bit to fit the requirement. I blame the missing space on houskeeping but wonder a little about the details and how I should adjust my lvcreate size to get df to report what I expect. Versions: First noted on redhat 4 but also reproduced in other distro Example above is from OpenSuse 10.3 so root@enterprise:~# uname -r 2.6.22.16-0.1-xen root@enterprise:~# df --version df (GNU coreutils) 6.9 -- ------------------------------------------------------------------- Techwiz, Peter Sjoberg PGP key (12F506C8) on keyserver & homepage Key fingerprint = 3DC2 CEBA 1590 B41A 3780 955A DB42 02BB 12F5 06C8 mailto:peters AT techwiz.ca http://www.techwiz.ca/~peters