“Used space†changes after shrinking partition
Clash Royale CLAN TAG#URR8PPP up vote
1
down vote
favorite
I booted my laptop with a Kubuntu 16.04 live USB and used KDE Partition Manager (version 1.2.1) to look at the internal HDD (/dev/sda). The main partition (/dev/sda3, ext4) was 442.91 GiB and Partition Manager reported that 41.29 GiB was used.
I then used KDE Partition Manager to shrink sda3 to 45 GiB. After shrinking was successfully completed (no errors reported), KDE Partition Manager reported that 35.03 GiB was used. The data on the partition shouldn't have changed, so how did this happen?
A (not particularly informed) guess of mine would be that Partition Manager was actually giving me an "estimate" of used space which improved after thge e shrinking operation; i.e., the actual data was always closer to 35 GiB. Or maybe a lot of data in the trash or temporary folders was removed. But that's still a big difference (about 20 percent), so I was wondering if anybody has seen this before or actually knows why this happens / should be expected.
Update: The laptop seems to be booting up and working fine after shrinking. This is no proof, of course, but there are no indications of data loss.
Update 2: The number of used inodes are the same between shrunk and unshrunk, and a checksum comparison of all files shows no differences, so I'm even more confident that there has been no data loss, which was the main practical concern. The question is still open but is more academic at this point.
partitioning ext4
asked Feb 10 at 16:58
Ratler
9710
add a comment |Â
up vote
1
down vote
favorite
I booted my laptop with a Kubuntu 16.04 live USB and used KDE Partition Manager (version 1.2.1) to look at the internal HDD (/dev/sda). The main partition (/dev/sda3, ext4) was 442.91 GiB and Partition Manager reported that 41.29 GiB was used.
I then used KDE Partition Manager to shrink sda3 to 45 GiB. After shrinking was successfully completed (no errors reported), KDE Partition Manager reported that 35.03 GiB was used. The data on the partition shouldn't have changed, so how did this happen?
A (not particularly informed) guess of mine would be that Partition Manager was actually giving me an "estimate" of used space which improved after thge e shrinking operation; i.e., the actual data was always closer to 35 GiB. Or maybe a lot of data in the trash or temporary folders was removed. But that's still a big difference (about 20 percent), so I was wondering if anybody has seen this before or actually knows why this happens / should be expected.
Update: The laptop seems to be booting up and working fine after shrinking. This is no proof, of course, but there are no indications of data loss.
Update 2: The number of used inodes are the same between shrunk and unshrunk, and a checksum comparison of all files shows no differences, so I'm even more confident that there has been no data loss, which was the main practical concern. The question is still open but is more academic at this point.
partitioning ext4
asked Feb 10 at 16:58
Ratler
9710
1
ext4 does not store data sequentially. Was the drive mounted when you shrank it? data loss is a possibility.
– ravery
Feb 10 at 17:07
@ravery Partition Manager would not have allowed to shrink ext4 if it was mounted. It allows growing it while mounted but that's fine. Btrfs can be both grown and shrunk when mounted. In fact that's the only way to resize btrfs, you can't resize it when it is unmounted.
– Andrius Å tikonas
Feb 11 at 17:22
@ravery, it was not mounted.
– Ratler
Feb 11 at 17:36
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I booted my laptop with a Kubuntu 16.04 live USB and used KDE Partition Manager (version 1.2.1) to look at the internal HDD (/dev/sda). The main partition (/dev/sda3, ext4) was 442.91 GiB and Partition Manager reported that 41.29 GiB was used.
I then used KDE Partition Manager to shrink sda3 to 45 GiB. After shrinking was successfully completed (no errors reported), KDE Partition Manager reported that 35.03 GiB was used. The data on the partition shouldn't have changed, so how did this happen?
A (not particularly informed) guess of mine would be that Partition Manager was actually giving me an "estimate" of used space which improved after thge e shrinking operation; i.e., the actual data was always closer to 35 GiB. Or maybe a lot of data in the trash or temporary folders was removed. But that's still a big difference (about 20 percent), so I was wondering if anybody has seen this before or actually knows why this happens / should be expected.
Update: The laptop seems to be booting up and working fine after shrinking. This is no proof, of course, but there are no indications of data loss.
Update 2: The number of used inodes are the same between shrunk and unshrunk, and a checksum comparison of all files shows no differences, so I'm even more confident that there has been no data loss, which was the main practical concern. The question is still open but is more academic at this point.
partitioning ext4
asked Feb 10 at 16:58
Ratler
9710
I booted my laptop with a Kubuntu 16.04 live USB and used KDE Partition Manager (version 1.2.1) to look at the internal HDD (/dev/sda). The main partition (/dev/sda3, ext4) was 442.91 GiB and Partition Manager reported that 41.29 GiB was used.
I then used KDE Partition Manager to shrink sda3 to 45 GiB. After shrinking was successfully completed (no errors reported), KDE Partition Manager reported that 35.03 GiB was used. The data on the partition shouldn't have changed, so how did this happen?
A (not particularly informed) guess of mine would be that Partition Manager was actually giving me an "estimate" of used space which improved after thge e shrinking operation; i.e., the actual data was always closer to 35 GiB. Or maybe a lot of data in the trash or temporary folders was removed. But that's still a big difference (about 20 percent), so I was wondering if anybody has seen this before or actually knows why this happens / should be expected.
Update: The laptop seems to be booting up and working fine after shrinking. This is no proof, of course, but there are no indications of data loss.
Update 2: The number of used inodes are the same between shrunk and unshrunk, and a checksum comparison of all files shows no differences, so I'm even more confident that there has been no data loss, which was the main practical concern. The question is still open but is more academic at this point.
partitioning ext4
partitioning ext4
asked Feb 10 at 16:58
Ratler
9710
asked Feb 10 at 16:58
Ratler
9710
edited Mar 8 at 17:32
asked Feb 10 at 16:58
Ratler
9710
asked Feb 10 at 16:58
Ratler
9710
asked Feb 10 at 16:58
Ratler
9710
9710
1
ext4 does not store data sequentially. Was the drive mounted when you shrank it? data loss is a possibility.
– ravery
Feb 10 at 17:07
@ravery Partition Manager would not have allowed to shrink ext4 if it was mounted. It allows growing it while mounted but that's fine. Btrfs can be both grown and shrunk when mounted. In fact that's the only way to resize btrfs, you can't resize it when it is unmounted.
– Andrius Å tikonas
Feb 11 at 17:22
@ravery, it was not mounted.
– Ratler
Feb 11 at 17:36
add a comment |Â
1
ext4 does not store data sequentially. Was the drive mounted when you shrank it? data loss is a possibility.
– ravery
Feb 10 at 17:07
@ravery Partition Manager would not have allowed to shrink ext4 if it was mounted. It allows growing it while mounted but that's fine. Btrfs can be both grown and shrunk when mounted. In fact that's the only way to resize btrfs, you can't resize it when it is unmounted.
– Andrius Å tikonas
Feb 11 at 17:22
@ravery, it was not mounted.
– Ratler
Feb 11 at 17:36
1
1
ext4 does not store data sequentially. Was the drive mounted when you shrank it? data loss is a possibility.
– ravery
Feb 10 at 17:07
ext4 does not store data sequentially. Was the drive mounted when you shrank it? data loss is a possibility.
– ravery
Feb 10 at 17:07
@ravery Partition Manager would not have allowed to shrink ext4 if it was mounted. It allows growing it while mounted but that's fine. Btrfs can be both grown and shrunk when mounted. In fact that's the only way to resize btrfs, you can't resize it when it is unmounted.
– Andrius Å tikonas
Feb 11 at 17:22
@ravery Partition Manager would not have allowed to shrink ext4 if it was mounted. It allows growing it while mounted but that's fine. Btrfs can be both grown and shrunk when mounted. In fact that's the only way to resize btrfs, you can't resize it when it is unmounted.
– Andrius Å tikonas
Feb 11 at 17:22
@ravery, it was not mounted.
– Ratler
Feb 11 at 17:36
@ravery, it was not mounted.
– Ratler
Feb 11 at 17:36
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
1
down vote
KDE Partition Manager gets used space from a few sources, some of which might be estimates. But as you said 20% looks a bit too much.
I think another thing is that partition resize tools might change some disk structures such as number of extents, so you need less space to store metadata.
answered Feb 11 at 17:22
Andrius Ã…Â tikonas
51037
Are extents related to fragmentation (that's what I gathered after a quick search)? Is there an easy way to check the metadata hypothesis (purely out of interest)? I have mountable gddrescue images of both the unshrunk and shrunk partition, and they seem to be working.
– Ratler
Feb 11 at 17:51
You can try to play with dumpe2fs and see if you can get metadata info. I haven't looked into what extents are in the technical sense, so my knowledge is similar to yours after a quick search.
– Andrius Å tikonas
Feb 11 at 21:35
I managed to corrupt the intermediate file, so can't use that for comparison. Comparing the unshrunk and shrunk images with dumpe2fs, I couldn't see anything that would explain this kind of difference (e.g., inodes or reserved GDT blocks are nowhere near the size of the difference).
– Ratler
Mar 9 at 10:45
add a comment |Â
up vote
1
down vote
The difference occurs due to the reserved-blocks-percentage which is a parameter of the file-system. The reserved-blocks-percentage can be changed with the tune2fs-command and has a default of 5% (see man tune2fs, look for the -m-option).
It looks as if your your file-system was adjusted to 2% before editing the partition and has been set back to 5% during resize.
answered Mar 8 at 18:49
mook765
3,0022819
I checked and both the unshrunk and shrunk have exactly 5 % reserved blocks (about 22 GiB and 1.9 GiB respectively). Would the reserved blocks show up as used space?
– Ratler
Mar 9 at 10:48
I thought you might be on to something there, but the numbers still don't add up: if the full partition had about 22 GiB in reserved blocks, and that changed to about 2.2 GiB after the first shrink operation, that would release about 20 GiB of space, which is much more than the 6 GiB change that I've seen (unless only part of the reserved blocks are reported as "used space"...).
– Ratler
Mar 9 at 10:57
@Ratler Yes, the reserved blocks will show up as used space. I think your file-system was set to 2% before resizing, but we can't check that anymore, partition is resized already...
– mook765
Mar 9 at 12:46
I actually made a backup image of the partition before resizing. This is how I could check the reserved block count: 5805286 (~22.2 GiB) for the unshrunk partition and 498072 (~1.9 GiB) for the shrunk partition. (I accidentally corrupted the image of the intermediate partition, so I can't check directly, but based on the other two, there's no reason to believe it would be anything other than 5 %.)
– Ratler
Mar 9 at 13:27
I don't know how you check the parameters of a file-system which resides in an image-file. However, try some testing: create a partition (or use a existing one) and play around with the reserved blocks percentage, also check what KDE Partition Manger reports under different conditions. Probably such a test helps you to see something.
– mook765
Mar 9 at 19:16
 |Â
show 1 more comment
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
KDE Partition Manager gets used space from a few sources, some of which might be estimates. But as you said 20% looks a bit too much.
I think another thing is that partition resize tools might change some disk structures such as number of extents, so you need less space to store metadata.
answered Feb 11 at 17:22
Andrius Ã…Â tikonas
51037
Are extents related to fragmentation (that's what I gathered after a quick search)? Is there an easy way to check the metadata hypothesis (purely out of interest)? I have mountable gddrescue images of both the unshrunk and shrunk partition, and they seem to be working.
– Ratler
Feb 11 at 17:51
You can try to play with dumpe2fs and see if you can get metadata info. I haven't looked into what extents are in the technical sense, so my knowledge is similar to yours after a quick search.
– Andrius Å tikonas
Feb 11 at 21:35
I managed to corrupt the intermediate file, so can't use that for comparison. Comparing the unshrunk and shrunk images with dumpe2fs, I couldn't see anything that would explain this kind of difference (e.g., inodes or reserved GDT blocks are nowhere near the size of the difference).
– Ratler
Mar 9 at 10:45
add a comment |Â
up vote
1
down vote
KDE Partition Manager gets used space from a few sources, some of which might be estimates. But as you said 20% looks a bit too much.
I think another thing is that partition resize tools might change some disk structures such as number of extents, so you need less space to store metadata.
answered Feb 11 at 17:22
Andrius Ã…Â tikonas
51037
Are extents related to fragmentation (that's what I gathered after a quick search)? Is there an easy way to check the metadata hypothesis (purely out of interest)? I have mountable gddrescue images of both the unshrunk and shrunk partition, and they seem to be working.
– Ratler
Feb 11 at 17:51
You can try to play with dumpe2fs and see if you can get metadata info. I haven't looked into what extents are in the technical sense, so my knowledge is similar to yours after a quick search.
– Andrius Å tikonas
Feb 11 at 21:35
I managed to corrupt the intermediate file, so can't use that for comparison. Comparing the unshrunk and shrunk images with dumpe2fs, I couldn't see anything that would explain this kind of difference (e.g., inodes or reserved GDT blocks are nowhere near the size of the difference).
– Ratler
Mar 9 at 10:45
add a comment |Â
up vote
1
down vote
up vote
1
down vote
KDE Partition Manager gets used space from a few sources, some of which might be estimates. But as you said 20% looks a bit too much.
I think another thing is that partition resize tools might change some disk structures such as number of extents, so you need less space to store metadata.
answered Feb 11 at 17:22
Andrius Ã…Â tikonas
51037
KDE Partition Manager gets used space from a few sources, some of which might be estimates. But as you said 20% looks a bit too much.
I think another thing is that partition resize tools might change some disk structures such as number of extents, so you need less space to store metadata.
answered Feb 11 at 17:22
Andrius Ã…Â tikonas
51037
answered Feb 11 at 17:22
Andrius Ã…Â tikonas
51037
answered Feb 11 at 17:22
Andrius Ã…Â tikonas
51037
answered Feb 11 at 17:22
Andrius Ã…Â tikonas
51037
51037
Are extents related to fragmentation (that's what I gathered after a quick search)? Is there an easy way to check the metadata hypothesis (purely out of interest)? I have mountable gddrescue images of both the unshrunk and shrunk partition, and they seem to be working.
– Ratler
Feb 11 at 17:51
You can try to play with dumpe2fs and see if you can get metadata info. I haven't looked into what extents are in the technical sense, so my knowledge is similar to yours after a quick search.
– Andrius Å tikonas
Feb 11 at 21:35
I managed to corrupt the intermediate file, so can't use that for comparison. Comparing the unshrunk and shrunk images with dumpe2fs, I couldn't see anything that would explain this kind of difference (e.g., inodes or reserved GDT blocks are nowhere near the size of the difference).
– Ratler
Mar 9 at 10:45
add a comment |Â
Are extents related to fragmentation (that's what I gathered after a quick search)? Is there an easy way to check the metadata hypothesis (purely out of interest)? I have mountable gddrescue images of both the unshrunk and shrunk partition, and they seem to be working.
– Ratler
Feb 11 at 17:51
You can try to play with dumpe2fs and see if you can get metadata info. I haven't looked into what extents are in the technical sense, so my knowledge is similar to yours after a quick search.
– Andrius Å tikonas
Feb 11 at 21:35
I managed to corrupt the intermediate file, so can't use that for comparison. Comparing the unshrunk and shrunk images with dumpe2fs, I couldn't see anything that would explain this kind of difference (e.g., inodes or reserved GDT blocks are nowhere near the size of the difference).
– Ratler
Mar 9 at 10:45
Are extents related to fragmentation (that's what I gathered after a quick search)? Is there an easy way to check the metadata hypothesis (purely out of interest)? I have mountable gddrescue images of both the unshrunk and shrunk partition, and they seem to be working.
– Ratler
Feb 11 at 17:51
Are extents related to fragmentation (that's what I gathered after a quick search)? Is there an easy way to check the metadata hypothesis (purely out of interest)? I have mountable gddrescue images of both the unshrunk and shrunk partition, and they seem to be working.
– Ratler
Feb 11 at 17:51
You can try to play with dumpe2fs and see if you can get metadata info. I haven't looked into what extents are in the technical sense, so my knowledge is similar to yours after a quick search.
– Andrius Å tikonas
Feb 11 at 21:35
You can try to play with dumpe2fs and see if you can get metadata info. I haven't looked into what extents are in the technical sense, so my knowledge is similar to yours after a quick search.
– Andrius Å tikonas
Feb 11 at 21:35
I managed to corrupt the intermediate file, so can't use that for comparison. Comparing the unshrunk and shrunk images with dumpe2fs, I couldn't see anything that would explain this kind of difference (e.g., inodes or reserved GDT blocks are nowhere near the size of the difference).
– Ratler
Mar 9 at 10:45
I managed to corrupt the intermediate file, so can't use that for comparison. Comparing the unshrunk and shrunk images with dumpe2fs, I couldn't see anything that would explain this kind of difference (e.g., inodes or reserved GDT blocks are nowhere near the size of the difference).
– Ratler
Mar 9 at 10:45
add a comment |Â
up vote
1
down vote
The difference occurs due to the reserved-blocks-percentage which is a parameter of the file-system. The reserved-blocks-percentage can be changed with the tune2fs-command and has a default of 5% (see man tune2fs, look for the -m-option).
It looks as if your your file-system was adjusted to 2% before editing the partition and has been set back to 5% during resize.
answered Mar 8 at 18:49
mook765
3,0022819
I checked and both the unshrunk and shrunk have exactly 5 % reserved blocks (about 22 GiB and 1.9 GiB respectively). Would the reserved blocks show up as used space?
– Ratler
Mar 9 at 10:48
I thought you might be on to something there, but the numbers still don't add up: if the full partition had about 22 GiB in reserved blocks, and that changed to about 2.2 GiB after the first shrink operation, that would release about 20 GiB of space, which is much more than the 6 GiB change that I've seen (unless only part of the reserved blocks are reported as "used space"...).
– Ratler
Mar 9 at 10:57
@Ratler Yes, the reserved blocks will show up as used space. I think your file-system was set to 2% before resizing, but we can't check that anymore, partition is resized already...
– mook765
Mar 9 at 12:46
I actually made a backup image of the partition before resizing. This is how I could check the reserved block count: 5805286 (~22.2 GiB) for the unshrunk partition and 498072 (~1.9 GiB) for the shrunk partition. (I accidentally corrupted the image of the intermediate partition, so I can't check directly, but based on the other two, there's no reason to believe it would be anything other than 5 %.)
– Ratler
Mar 9 at 13:27
I don't know how you check the parameters of a file-system which resides in an image-file. However, try some testing: create a partition (or use a existing one) and play around with the reserved blocks percentage, also check what KDE Partition Manger reports under different conditions. Probably such a test helps you to see something.
– mook765
Mar 9 at 19:16
 |Â
show 1 more comment
up vote
1
down vote
The difference occurs due to the reserved-blocks-percentage which is a parameter of the file-system. The reserved-blocks-percentage can be changed with the tune2fs-command and has a default of 5% (see man tune2fs, look for the -m-option).
It looks as if your your file-system was adjusted to 2% before editing the partition and has been set back to 5% during resize.
answered Mar 8 at 18:49
mook765
3,0022819
I checked and both the unshrunk and shrunk have exactly 5 % reserved blocks (about 22 GiB and 1.9 GiB respectively). Would the reserved blocks show up as used space?
– Ratler
Mar 9 at 10:48
I thought you might be on to something there, but the numbers still don't add up: if the full partition had about 22 GiB in reserved blocks, and that changed to about 2.2 GiB after the first shrink operation, that would release about 20 GiB of space, which is much more than the 6 GiB change that I've seen (unless only part of the reserved blocks are reported as "used space"...).
– Ratler
Mar 9 at 10:57
@Ratler Yes, the reserved blocks will show up as used space. I think your file-system was set to 2% before resizing, but we can't check that anymore, partition is resized already...
– mook765
Mar 9 at 12:46
I actually made a backup image of the partition before resizing. This is how I could check the reserved block count: 5805286 (~22.2 GiB) for the unshrunk partition and 498072 (~1.9 GiB) for the shrunk partition. (I accidentally corrupted the image of the intermediate partition, so I can't check directly, but based on the other two, there's no reason to believe it would be anything other than 5 %.)
– Ratler
Mar 9 at 13:27
I don't know how you check the parameters of a file-system which resides in an image-file. However, try some testing: create a partition (or use a existing one) and play around with the reserved blocks percentage, also check what KDE Partition Manger reports under different conditions. Probably such a test helps you to see something.
– mook765
Mar 9 at 19:16
 |Â
show 1 more comment
up vote
1
down vote
up vote
1
down vote
The difference occurs due to the reserved-blocks-percentage which is a parameter of the file-system. The reserved-blocks-percentage can be changed with the tune2fs-command and has a default of 5% (see man tune2fs, look for the -m-option).
It looks as if your your file-system was adjusted to 2% before editing the partition and has been set back to 5% during resize.
answered Mar 8 at 18:49
mook765
3,0022819
The difference occurs due to the reserved-blocks-percentage which is a parameter of the file-system. The reserved-blocks-percentage can be changed with the tune2fs-command and has a default of 5% (see man tune2fs, look for the -m-option).
It looks as if your your file-system was adjusted to 2% before editing the partition and has been set back to 5% during resize.
answered Mar 8 at 18:49
mook765
3,0022819
answered Mar 8 at 18:49
mook765
3,0022819
answered Mar 8 at 18:49
mook765
3,0022819
answered Mar 8 at 18:49
mook765
3,0022819
3,0022819
I checked and both the unshrunk and shrunk have exactly 5 % reserved blocks (about 22 GiB and 1.9 GiB respectively). Would the reserved blocks show up as used space?
– Ratler
Mar 9 at 10:48
I thought you might be on to something there, but the numbers still don't add up: if the full partition had about 22 GiB in reserved blocks, and that changed to about 2.2 GiB after the first shrink operation, that would release about 20 GiB of space, which is much more than the 6 GiB change that I've seen (unless only part of the reserved blocks are reported as "used space"...).
– Ratler
Mar 9 at 10:57
@Ratler Yes, the reserved blocks will show up as used space. I think your file-system was set to 2% before resizing, but we can't check that anymore, partition is resized already...
– mook765
Mar 9 at 12:46
I actually made a backup image of the partition before resizing. This is how I could check the reserved block count: 5805286 (~22.2 GiB) for the unshrunk partition and 498072 (~1.9 GiB) for the shrunk partition. (I accidentally corrupted the image of the intermediate partition, so I can't check directly, but based on the other two, there's no reason to believe it would be anything other than 5 %.)
– Ratler
Mar 9 at 13:27
I don't know how you check the parameters of a file-system which resides in an image-file. However, try some testing: create a partition (or use a existing one) and play around with the reserved blocks percentage, also check what KDE Partition Manger reports under different conditions. Probably such a test helps you to see something.
– mook765
Mar 9 at 19:16
 |Â
show 1 more comment
I checked and both the unshrunk and shrunk have exactly 5 % reserved blocks (about 22 GiB and 1.9 GiB respectively). Would the reserved blocks show up as used space?
– Ratler
Mar 9 at 10:48
I thought you might be on to something there, but the numbers still don't add up: if the full partition had about 22 GiB in reserved blocks, and that changed to about 2.2 GiB after the first shrink operation, that would release about 20 GiB of space, which is much more than the 6 GiB change that I've seen (unless only part of the reserved blocks are reported as "used space"...).
– Ratler
Mar 9 at 10:57
@Ratler Yes, the reserved blocks will show up as used space. I think your file-system was set to 2% before resizing, but we can't check that anymore, partition is resized already...
– mook765
Mar 9 at 12:46
I actually made a backup image of the partition before resizing. This is how I could check the reserved block count: 5805286 (~22.2 GiB) for the unshrunk partition and 498072 (~1.9 GiB) for the shrunk partition. (I accidentally corrupted the image of the intermediate partition, so I can't check directly, but based on the other two, there's no reason to believe it would be anything other than 5 %.)
– Ratler
Mar 9 at 13:27
I don't know how you check the parameters of a file-system which resides in an image-file. However, try some testing: create a partition (or use a existing one) and play around with the reserved blocks percentage, also check what KDE Partition Manger reports under different conditions. Probably such a test helps you to see something.
– mook765
Mar 9 at 19:16
I checked and both the unshrunk and shrunk have exactly 5 % reserved blocks (about 22 GiB and 1.9 GiB respectively). Would the reserved blocks show up as used space?
– Ratler
Mar 9 at 10:48
I checked and both the unshrunk and shrunk have exactly 5 % reserved blocks (about 22 GiB and 1.9 GiB respectively). Would the reserved blocks show up as used space?
– Ratler
Mar 9 at 10:48
I thought you might be on to something there, but the numbers still don't add up: if the full partition had about 22 GiB in reserved blocks, and that changed to about 2.2 GiB after the first shrink operation, that would release about 20 GiB of space, which is much more than the 6 GiB change that I've seen (unless only part of the reserved blocks are reported as "used space"...).
– Ratler
Mar 9 at 10:57
I thought you might be on to something there, but the numbers still don't add up: if the full partition had about 22 GiB in reserved blocks, and that changed to about 2.2 GiB after the first shrink operation, that would release about 20 GiB of space, which is much more than the 6 GiB change that I've seen (unless only part of the reserved blocks are reported as "used space"...).
– Ratler
Mar 9 at 10:57
@Ratler Yes, the reserved blocks will show up as used space. I think your file-system was set to 2% before resizing, but we can't check that anymore, partition is resized already...
– mook765
Mar 9 at 12:46
@Ratler Yes, the reserved blocks will show up as used space. I think your file-system was set to 2% before resizing, but we can't check that anymore, partition is resized already...
– mook765
Mar 9 at 12:46
I actually made a backup image of the partition before resizing. This is how I could check the reserved block count: 5805286 (~22.2 GiB) for the unshrunk partition and 498072 (~1.9 GiB) for the shrunk partition. (I accidentally corrupted the image of the intermediate partition, so I can't check directly, but based on the other two, there's no reason to believe it would be anything other than 5 %.)
– Ratler
Mar 9 at 13:27
I actually made a backup image of the partition before resizing. This is how I could check the reserved block count: 5805286 (~22.2 GiB) for the unshrunk partition and 498072 (~1.9 GiB) for the shrunk partition. (I accidentally corrupted the image of the intermediate partition, so I can't check directly, but based on the other two, there's no reason to believe it would be anything other than 5 %.)
– Ratler
Mar 9 at 13:27
I don't know how you check the parameters of a file-system which resides in an image-file. However, try some testing: create a partition (or use a existing one) and play around with the reserved blocks percentage, also check what KDE Partition Manger reports under different conditions. Probably such a test helps you to see something.
– mook765
Mar 9 at 19:16
I don't know how you check the parameters of a file-system which resides in an image-file. However, try some testing: create a partition (or use a existing one) and play around with the reserved blocks percentage, also check what KDE Partition Manger reports under different conditions. Probably such a test helps you to see something.
– mook765
Mar 9 at 19:16
 |Â
show 1 more comment
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1004904%2fused-space-changes-after-shrinking-partition%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
1
ext4 does not store data sequentially. Was the drive mounted when you shrank it? data loss is a possibility.
– ravery
Feb 10 at 17:07
@ravery Partition Manager would not have allowed to shrink ext4 if it was mounted. It allows growing it while mounted but that's fine. Btrfs can be both grown and shrunk when mounted. In fact that's the only way to resize btrfs, you can't resize it when it is unmounted.
– Andrius Å tikonas
Feb 11 at 17:22
@ravery, it was not mounted.
– Ratler
Feb 11 at 17:36