LVM question. Missing about 11GB of Space..

[Alexander Dalloz]

Am Sa, den 29.10.2005 schrieb Michael D. Setzer II um 17:19:

> In doing a backup of a 250GB drive, I was surprised to have a 
> compressed image that was larger than the used space. In the past, 
> I've compressed an 80GB drive with 3 OS's, and get a 14GB image. 
> This is a 250GB drive with only 1 OS, and it is producing an 18GB 
> image. All free space is zeroed out.  In doing some research, it 
> appears that about 5% of the LVM partition is being used in some 
> fashion that I am not aware of. 
> 
> The drive shows the volume size as 229GB with 12GB uses, and 
> 206GB Free. That leaves about 11 - 12 GB missing. 
> 
> Whatever is in this 5% of the drive doesn't appear to compress very 
> well with either lzop or gzip. With lzop the image is about 18GB and 
> 16GB with gzip, but lzop only takes about 2 hours, whereas gzip 
> takes about 3 1/2 hours. The image only seems to be runing fine 
> until it gets to the end were this 5% seems to be, and it grows 
> rapidly. 
> 
> Any info on what this 5% is. I'm using g4l, which uses dd to copy the 
> raw partition information, and uses lzop or gzip compression. I was 
> thinking it might be some kind of swap, but why it would be 5% of 
> the disk size, as compared to the amount of ram. 

This has nothing to do with LVM. Please see "man mkfs.ext{3,2}" -> -m
reserved-blocks-percentage

"Specify  the  percentage  of the filesystem blocks reserved for the
super-user.  This value defaults to 5%."

Alexander


-- 
Alexander Dalloz | Enger, Germany | GPG http://pgp.mit.edu 0xB366A773
legal statement: http://www.uni-x.org/legal.html
Fedora Core 2 GNU/Linux on Athlon with kernel 2.6.11-1.35_FC2smp 
Serendipity 18:12:02 up 15:12, 16 users, 0.15, 0.26, 0.15 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20051029/eb483be0/attachment-0001.sig>