-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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.
Thanks.
+----------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor Guam Community College Computer Center mailto:mikes@kuentos.guam.net mailto:msetzerii@gmail.com http://www.guam.net/home/mikes Guam - Where America's Day Begins +----------------------------------------------------------+
http://setiathome.berkeley.edu Number of Seti Units Returned: 18,388 Processing time: 32 years, 71 days, 5 hours, 36 minutes (Total Hours: 282,030)
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
Am Sa, den 29.10.2005 schrieb Alexander Dalloz um 18:14:
Am Sa, den 29.10.2005 schrieb Michael D. Setzer II um 17:19:
The drive shows the volume size as 229GB with 12GB uses, and 206GB Free. That leaves about 11 - 12 GB missing.
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
Missed to point you to yesterdays verbose thread "Fedora 4 maxtor 160Gb 30 gb missing;" about exactly the same topic. It covers both the fact about the reserved super-user space as well that a 250GB drive does not mean it really has 250GB of usable space (multiplier of 1024 v.s 1000) - example: fdisk says about my 80GB harddrive "/dev/hda: 80.0 GByte, 80026361856 Byte". If you calculate that into GB you get 74,53GB from hardware point of view. Other drive vendors can handle that different so that a 80GB drive really offers 80GB of storage space.
Alexander
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 29 Oct 2005 at 18:14, Alexander Dalloz wrote:
From: Alexander Dalloz ad+lists@uni-x.org To: For users of Fedora Core releases fedora-list@redhat.com Date sent: Sat, 29 Oct 2005 18:14:47 +0200 Subject: Re: LVM question. Missing about 11GB of Space.. Send reply to: For users of Fedora Core releases fedora-list@redhat.com mailto:fedora-list-request@redhat.com?subject=unsubscribe mailto:fedora-list-request@redhat.com?subject=subscribe
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%."
Thanks, that explains why it was setup that way, but it was done automatically with the installation of the Fedora, so can it be changed after the fact?? Or is there a way to atleast blank out the reserved area with nulls. I zero out all the free space, but it doesn't have access to that area.
I do now that the 250GB drive is 251,000,193,024 bytes, and produces the /dev/hda1 as 104,391 (1 to 13) and /dev/hda2 as 245,007,315 (14 - 30515).
If I can zero out this area, it should reduce the size of the g4l images, and speed up the restore process. With the 80MB drives, it is less than 2GB, but with the 5% of the 250GB drive is is larger.
Thanks again.
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
+----------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor Guam Community College Computer Center mailto:mikes@kuentos.guam.net mailto:msetzerii@gmail.com http://www.guam.net/home/mikes Guam - Where America's Day Begins +----------------------------------------------------------+
http://setiathome.berkeley.edu Number of Seti Units Returned: 18,388 Processing time: 32 years, 71 days, 5 hours, 36 minutes (Total Hours: 282,030)
Michael D. Setzer II wrote:
Thanks, that explains why it was setup that way, but it was done automatically with the installation of the Fedora, so can it be changed after the fact?? Or is there a way to atleast blank out the
tune2fs -m 0 /dev/hda2
should do this. However... the reservation of this space for processes running under the flag of root is actually useful, especially if processes running as something else have managed to exhaust all the apparently availble space on your drive... you can still log in as root and have some room to manouever.
-Andy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 29 Oct 2005 at 19:05, Andy Green wrote:
Date sent: Sat, 29 Oct 2005 19:05:17 +0100 From: Andy Green andy@warmcat.com To: For users of Fedora Core releases fedora-list@redhat.com Subject: Re: LVM question. Missing about 11GB of Space.. Send reply to: For users of Fedora Core releases fedora-list@redhat.com mailto:fedora-list-request@redhat.com?subject=unsubscribe mailto:fedora-list-request@redhat.com?subject=subscribe
Michael D. Setzer II wrote:
Thanks, that explains why it was setup that way, but it was done automatically with the installation of the Fedora, so can it be changed after the fact?? Or is there a way to atleast blank out the
tune2fs -m 0 /dev/hda2
should do this. However... the reservation of this space for processes running under the flag of root is actually useful, especially if processes running as something else have managed to exhaust all the apparently availble space on your drive... you can still log in as root and have some room to manouever.
I wasn't looking at going ot 0, but what would be a more reasonable number than 12GB. Even the 12GB would be fine, if there was a way to make all or most of it nulls, so it would compress greatly The rest of the drives 206GB of space was all nulls, and compress very well.
Thanks.
-Andy
+----------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor Guam Community College Computer Center mailto:mikes@kuentos.guam.net mailto:msetzerii@gmail.com http://www.guam.net/home/mikes Guam - Where America's Day Begins +----------------------------------------------------------+
http://setiathome.berkeley.edu Number of Seti Units Returned: 18,388 Processing time: 32 years, 71 days, 5 hours, 36 minutes (Total Hours: 282,030)
-
Alexander Dalloz -
Andy Green -
Michael D. Setzer II