resize2fs giving weird results

[RandomUsername]

Hi,

I am resizing the main lv and filesystem so I can create an encrypted partition on my Bubba Two using DM-Crypt and LUKS.

What's weird is if, for example, I resize /dev/mapper/bubba-storage to 807G, upon remounting df -h tells me the filesystem is only 795G in size. I've tried a few different sizes and also tried entering the target size in megabytes (using M instead of G) but each time it gets resized to something different to my chosen value. I did try entering the size in blocks instead and although it got resized to the right number of blocks it was still reported by df -h as the wrong value in GB. Both df and resize2fs use base 2 values for GB by default so I'm at a loss to explain this.

Google's turned up nothing, however I've not used resize2fs a great deal so it might be obvious and expected behaviour.

Anyone?

TIA.

[RandomUsername]

OK, ignore me. I think I'm not taking into account the reserved space for the OS and swap space.

[EDIT]Or perhaps not. It appears the swap and OS are on separate primary partitions (only had the Bubba Two for a couple of days so I'm still finding my way around it).

Also, The partition the lv is on is 989 GB and by default /dev/mapper/storage is 907 GB (this is on a 1TB drive BTW) so there's over 80 GB of overhead in maintaining the logical volume? Seems like a lot but everything I know about lvm I've learnt since the Bubba arrived.

[RandomUsername]

Right, I think I've finally answered my own question. df -h doesn't count the reserved space of a filesystem (that's my new thing I've learnt today) so it appears that the Bubba installation sets the ext3 filesystem to reserve 10% of the space rather than the default 5%. Is there any reason for this? With bigger disks that's a lot of space to reserve.

[EDIT]Except tune2fs -l /dev/mapper/bubba-storage shows the reserved space as 1% - Arggh!