Macrium Reflect 8 Update Discussion

camelia said:

Do you suggest me to create a new MR backup just in case?

Camelia

You don't need a new backup.

You can do either of these things....








Top picture: Right click C: and choose: Extend partition ...and add the 177 GB unallocated to C:

OR.....

Bottom picture: Right click the 177 GB unallocated and choose: New Simple Volume ...and make a D: drive.






Then... AFTER you choose one of the options above... THEN you can make a new backup.

camelia said:

500GB TOSHIBA is an spinning disk too

Thanks
Camelia

Attachment 345729

Thanks for that. The total size of your C: partition is 4 times the actual size of the space used. That is very very generous and the odds of that being consumed by natural growth of the OS is so slim as to be virtually nill.

As has been discussed and explained several times, if you extend the C: partition to include the 177GB unallocated space, you may have issues if you ever wanted to shrink it and reclaim some space for another use. We've been over this and how it applies to spinners. You already have 4 times enough room based on current usage, and doing the extension would give you 8+ times enough room. That is overkill.

Best advice right now is to just leave it alone, leave it unallocated. If it is bothersome that you have unallocated space just sitting there, create a new partition, give it a name like Camelia Spare, assign it a drive letter. Then you can use it to store anything you wish apart and separate from the OS. That space is simply not needed in the C: partition.

f14tomcat said:

Thanks for that. The total size of your C: partition is 4 times the actual size of the space used. That is very very generous and the odds of that being consumed by natural growth of the OS is so slim as to be virtually nill.

As has been discussed and explained several times, if you extend the C: partition to include the 177GB unallocated space, you may have issues if you ever wanted to shrink it and reclaim some space for another use. We've been over this and how it applies to spinners. You already have 4 times enough room based on current usage, and doing the extension would give you 8+ times enough room. That is overkill.

Best advice right now is to just leave it alone, leave it unallocated. If it is bothersome that you have unallocated space just sitting there, create a new partition, give it a name like Camelia Spare, assign it a drive letter. Then you can use it to store anything you wish apart and separate from the OS. That space is simply not needed in the C: partition.

I totally disagree leaving it unallocated is best advice. I cannot see point of leaving space blank. Either extend it or create new partitions. Leaving it blank will just increase rate of defragmentation on the existing partition.

Personally I would create a new partition for data as that is relatively static, leaving a lot more spare space free on C drive reducing the rate of defragmentation. Even expanding the drive only will reduce rate of defragmentation as more working space i.e. not using the space is not efficient and could lead to a performance reduction.

cereberus said:

I totally disagree leaving it unallocated is best advice. I cannot see point of leaving space blank. Either extend it or create new partitions. Leaving it blank will just increase rate of defragmentation on the existing partition.

Personally I would create a new partition for data as that is relatively static, leaving a lot more spare space free on C drive reducing the rate of defragmentation. Even expanding the drive only will reduce rate of defragmentation as more working space i.e. not using the space is not efficient and could lead to a performance reduction.

These are HDDs on the system. Does all you say still hold true?

[QUOTE=f14tomcat;2294347]These are HDDs on the system. Does all you say still hold true?[/QUOTE)]
Sure, if OP puts all data on a smaller partition as well as OS, then there is less free space for working and that must lead to more defragmentation of the HDD, and as partition fills up the defrag rate will accelerate which could reduce performance. Basically, not allocating space is the same as using a smaller drive. Defragmentation is affected by the amount of free space. Once you go over a certain level (say 90%) full, it can sharply rise. Obviously, the more free space, the longer it will take to reach 90% full level.

In any case, eventually OP will get nuisance warnings if partition is getting full when there is still plenty of free space in reality.

In simple terms, maximising amount of free space is ALWAYS a good plan.

[QUOTE=cereberus;2294447]

f14tomcat said:

These are HDDs on the system. Does all you say still hold true?[/QUOTE)]
Sure, if OP puts all data on a smaller partition as well as OS, then there is less free space for working and that must lead to more defragmentation of the HDD, and as partition fills up the defrag rate will accelerate which could reduce performance. Basically, not allocating space is the same as using a smaller drive. Defragmentation is affected by the amount of free space. Once you go over a certain level (say 90%) full, it can sharply rise. Obviously, the more free space, the longer it will take to reach 90% full level.

In any case, eventually OP will get nuisance warnings if partition is getting full when there is still plenty of free space in reality.

In simple terms, maximising amount of free space is ALWAYS a good plan.

Do you mean "Fragmentation" and not DE-fragmentation ?
Fragmentation also occurs when there's an attempt to write in blocks that are marked deleted but not empty. Eventually, when enough space is filled they will have to be erased and that's when most slowdowns occur.
SSDs are naturally "Fragmented", it really doesn't matter where data is located, all cells are equally available for writing at same time.
SSDs also have problem with cells with data marked as deleted. When an SSD is too full, cells have to be erased before writing to them which slows everything down. Modern SSDs with help from OS have mechanism built in that periodically erases all cells marked for deletion but not really empty. "Garbage collection" also induced by Trim command does just that, erases all cells with data marked as deleted so they can be written to without delay.
Earlier SSDs didn't have that function in the firmware so to speed them up we had to erase them periodically or performance would drop like a rock. That also induced a lot of writing cycles and reduced life span.

[QUOTE=cereberus;2294447]

f14tomcat said:

These are HDDs on the system. Does all you say still hold true?[/QUOTE)]
Sure, if OP puts all data on a smaller partition as well as OS, then there is less free space for working and that must lead to more defragmentation of the HDD, and as partition fills up the defrag rate will accelerate which could reduce performance. Basically, not allocating space is the same as using a smaller drive. Defragmentation is affected by the amount of free space. Once you go over a certain level (say 90%) full, it can sharply rise. Obviously, the more free space, the longer it will take to reach 90% full level.

In any case, eventually OP will get nuisance warnings if partition is getting full when there is still plenty of free space in reality.

In simple terms, maximising amount of free space is ALWAYS a good plan.

Thanks.

Given the current free space is 218GB and after extension would be 395GB, that would give an ~ used of 15.2%. That means Camelia could grow her current OS and Data to be 6 1/2 times it's current size before total fill up. Unlikely.

But, who's to say. So, Camelia, just to be on the safe side, extend the C: partition to include any and all possible empty/unused/unallocated space on your system that is available for the purpose.

Going forward, if you are in the need to increase that 579 System Reserved or need a small partition available for any other purpose, we will deal with it at the time.

[QUOTE=CountMike;2294479]

cereberus said:

Do you mean "Fragmentation" and not DE-fragmentation ?
Fragmentation also occurs when there's an attempt to write in blocks that are marked deleted but not empty. Eventually, when enough space is filled they will have to be erased and that's when most slowdowns occur.
SSDs are naturally "Fragmented", it really doesn't matter where data is located, all cells are equally available for writing at same time.
SSDs also have problem with cells with data marked as deleted. When an SSD is too full, cells have to be erased before writing to them which slows everything down. Modern SSDs with help from OS have mechanism built in that periodically erases all cells marked for deletion but not really empty. "Garbage collection" also induced by Trim command does just that, erases all cells with data marked as deleted so they can be written to without delay.
Earlier SSDs didn't have that function in the firmware so to speed them up we had to erase them periodically or performance would drop like a rock. That also induced a lot of writing cycles and reduced life span.

yeah - I meant fragmentation of course.