How much defragmentation is enough?

English Install/Boot/Login
1

I’ve installed SuSE 11.2 onto an acer Travelmate 2310 with Windows XP. The laptop started out with three partitions – one a small hidden acer partition, one ( C: ) the main Windows partition, and one ( D: ) to support a bios-enabled disk-to-disk backup capability.

I was hoping I would be able to shrink both C and D. I ran the defragmentation program four or five times against the C: partition. Each time I ran it, the program left a small moveable file at the very end of the partition. Is this file a deliberate Microsoft ploy to thwart partition shrinking?

The Linux install did allow me to shrink D: to about 150 MB. Shrinking C: was not even an option, however. Is this because the main Windows XP partition is unshrinkable? Is there any way to determine what file resides at the end of the partition?

There is one minor problem with the 11.2 install. When I accept the recommended configuration then try to resize, the install program refuses to expand the Linux partitions beyond the recommended size values. I had to delete the recommended Linux partitions and recreate them manually, using expert mode.

I haven’t seen a bios option for disk-to-disk backup before. What will happen now that D: has shrunk to a point? I doubt that bios has access to the partition table! To be safe, I’ve turned the option off.

2

Well shrinking C in this case will leave a gap between the Windows c: and the D: partitions. In order to allow a continuous area for the Linux install you would need to move D: to the end of C: I doubt this is possible in Windows. You would need a real partition manager like parted magic.

Any partitioner should move those files at the end. The reason to defrag is to present the largest uncluttered space. I believe the file you see is the duplicate format table that Windows maintains.

3

Each time I ran it, the program left a small moveable file at the very end of the partition. Is this file a deliberate Microsoft ploy to thwart partition shrinking?
Would Microsofton do such a thing? Well I will let you decide.

4

Please show us the output of fdisk l that is a lower-case L from a su - terminal.

The Linux install did allow me to shrink D: to about 150 MB. Shrinking C: was not even an option, however. Is this because the main Windows XP partition is unshrinkable?
Yes, you could try other tools to move the files in question, but I don’t like your chances.

Is this because the main Windows XP partition is unshrinkable? Is there any way to determine what file resides at the end of the partition?
I can’t answer this, I think this one is best asked on a windows forum, although there are experienced users of windows here also who may be able to answer this.

5

First shutdown system file recover points
Next adjust swap to be adjustable from 0 to recommended at each boot
Next reboot & defrag
Next shrink C: Create Logical Extended drive in free space from C: and make a logical drive large enough to hold D:
Next move old D: into new extended logical drive
Make sure D: in new logical is working OK before you kill old D: partition
You should be able at this point to delete the old D: partition, resize the extended partition to whole disk and
install Linux as desired into the extended by creating logical drives in extended. You could also not expand the extended
partition to whole disk remainder and create Linux swap in extended and make primary partition 4 Linux.

just some of my thoughts

6

Thanks for the information, suggestions and ideas.

Here’s a crazy idea of my own: As an alternative to shinking, couldn’t we create a giant FAT file in the middle of the C partition and use it to hold an ext file-system? I remember my first Linux – Corel – offered something similar.

7

What you were referring to was making a virtual filesystem under windose. Early Linux distro’s offered that as an alternate way to run but where the problem came was with M$ totally mismanaging hdd space a crash would take out windows and in most cases the fake filesystem as well. After many lost everything it was abandoned in mainstream distro’s in favor of a real virtual host/client system. BTW it wasn’t FAT because Linux can’t now or ever function under the restrictions of FAT. It was basically a unique iso image of a drive if I recall. Modern Windows also can’t handle that old type of Linux launch because it required dropping to the command interpreter which modern windows would have to be forced to do.

I recommend you do it right and learn the right way … unlearn the M$ wrong way.

Here are some more ways to have a healthy Linux system:

  1. Use whole drive for Linux set up with (swap) Partition 1(sda1), Extended Partition as 2 (sda2) using whole drive, make logical drive 1 (sda5) part of extended space big enough to install windows, logical drive 2 (sda6) another section with-in extended as windows file sharing between the OS’s, logical drive 3 (sda7) as Linux root (/), and if you like you can also define a logical drive 4, 5, 6, 7 … for other purposes.
  2. Another way would see Linux as the whole hdd with virtualBox installed and windows installed as a virtual client from with-in Linux such that you can have both running (if your hardware is strong enough).

Before you tackle things pls take the time to read some excellent how-to’s in this forum and others about partitioning techniques. Know in advance what you really want and how best to achieve it.

8

On 2010-10-03 01:06, Iconoclasmic wrote:

> I was hoping I would be able to shrink both C and D. I ran the
> defragmentation program four or five times against the C: partition.
> Each time I ran it, the program left a small moveable file at the very
> end of the partition. Is this file a deliberate Microsoft ploy to
> thwart partition shrinking?

Not every problem needs a conspiracy theory to explain it :slight_smile:

Many windows tools store unmovable files at the very end of the disk, even before Linux existed.
Typically disaster prevention tools stored a copy of the boot sector, fat table, and directory
entries there - so as to be able to recover from accidental erasure of files, disk format, etc. Why
there? Because at the end of the disk is an easy place to locate them when the fat is destroyed, and
because a format starts from the disk start, not the end.

The trick is knowing what tool it is, disable it for a while, and delete its files.

If it is windows 7, by the way, its help has entries on how to do a shrink from inside, what to
disable. But it works best if you run it just after windows installation (or recovery from recovery
partition), before installing all your stuff.

Otherwise, commercial tools could shrink it.

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

9

Many windows tools store unmovable files at the very end of the disk, even before Linux existed.
Typically disaster prevention tools stored a copy of the boot sector, fat table, and directory
entries there - so as to be able to recover from accidental erasure of files, disk format, etc. Why
there? Because at the end of the disk is an easy place to locate them when the fat is destroyed, and
because a format starts from the disk start, not the end.

I thought we had progressed passed the file allocation table, actually I thought even windows managed that. Yes I know it is still used on USB sticks etc.
Is there really a reason for any tool to do this now?

10

You are right! FAT was for windows 98 and before possibly even windows me … not sure. NTFS became the new FAT-less standard for XP and beyond.
It’s only use is with USB sticks, & Floppies.

11

On 2010-10-03 17:06, dvhenry wrote:

> I thought we had progressed passed the file allocation table, actually
> I thought even windows managed that. Yes I know it is still used on USB
> sticks etc.
> Is there really a reason for any tool to do this now?

The same reason holds for NTFS, but with different structure.

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

12

But why would there be a requirement to have files at that end of the file system, if the file system is damaged or destroyed that end can get hit also, it has no immunity.
I could be wrong, but I don’t see this occurring in linux.

13

Why
there? Because at the end of the disk is an easy place to locate them when the fat is destroyed, and
because a format starts from the disk start, not the end.

The only reliable place to store a copy of this type of data is still somewhere other than the disk the partition is on, that won’t change any time soon.

14

and
because a format starts from the disk start, not the end.

But it does finish at the end!

15

++1 to last three posts. I could ramble more about the real reasoning behind windows partitioning/file management but too much is rehashed already

16

On 2010-10-04 01:36, dvhenry wrote:
>
>> and
>> because a format starts from the disk start, not the end.
>
> But it does finish at the end!

No.

One, a quick format only erases the metastructure at the start of the disk. It does not erase data.

Two, many people notice what they are doing before it finishes, and pull the plug.

Believe me, storing a copy of the metadata at the end of the disk works (in windows) quite often. It
is not Microsoft, this technique started with companies like Norton, Symantec, and many others.

It is old stuff, you must be young >:-)

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

17

One, a quick format only erases the metastructure at the start of the disk. It does not erase data.

I agree, But it does not erase the data weather it is at the start, in the middle, or at the end of the disk.

Two, many people notice what they are doing before it finishes, and pull the plug.

I have always seen this as a bad thing, If you allow the process to finish you at least know what you have got to work with, pull the plug part way through and what do you have???

It is old stuff, you must be young >:-)

I’m getting older as I type replies on this forum, at this rate I will be 98 by the end of the week!

18

Ahuh! you will be re-formatted with white beard and wrinkles and unable to pull the plug before the process completes

19

On 2010-10-04 14:06, dvhenry wrote:
>
>> One, a quick format only erases the metastructure at the start of the
>> disk. It does not erase data.
>
> I agree, But it does not erase the data weather it is at the start, in
> the middle, or at the end of the disk.

Yes, that is so.

However, suppose the user quick formatted a FAT disk (I talk about FAT because I know its internals,
but not NTFS internals). The process erases the FAT table and at least the main directory entries.
Not the data, but you can not locate any data in the disk, except by scanning content, because the
indexes to the data have been erased.

Now you know there is a second copy of the FAT done by a damage mitigation program. How do you find
it? Well either you scan the full disk searching for a pattern, or… look in the very end of the
disk. Not the start, because that’s dangerously near the FAT, and because the second format can
change sizes of those tables and overwrite it. You place the recovery data on one end of the disk:
the start is already in use, so you use the end.

In fact, it is usually only one sector at the very end, a sector with an easy to find signature and
a checksum. This sector contains a map to where are the rest of the data recovery files. Those files
can also be at the end, or nearby, and fragmented (because there is a map).

>> Two, many people notice what they are doing before it finishes, and pull
>> the plug.
>
> I have always seen this as a bad thing, If you allow the process to
> finish you at least know what you have got to work with, pull the plug
> part way through and what do you have???

Surprisingly, you can recover part of the disk. And if the process is a real format (erases data)
and it does not respond to the frantic presses on the “stop” button, the only recourse is the plug.

>> It is old stuff, you must be young >:-)
>
> I’m getting older as I type replies on this forum, at this rate I will
> be 98 by the end of the week!

:slight_smile:

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

20

However, suppose the user quick formatted a FAT disk (I talk about FAT because I know its internals,
but not NTFS internals). The process erases the FAT table and at least the main directory entries.
Not the data, but you can not locate any data in the disk, except by scanning content, because the
indexes to the data have been erased.

Now you know there is a second copy of the FAT done by a damage mitigation program. How do you find
it? Well either you scan the full disk searching for a pattern, or… look in the very end of the
disk. Not the start, because that’s dangerously near the FAT, and because the second format can
change sizes of those tables and overwrite it. You place the recovery data on one end of the disk:
the start is already in use, so you use the end.

In fact, it is usually only one sector at the very end, a sector with an easy to find signature and
a checksum. This sector contains a map to where are the rest of the data recovery files. Those files
can also be at the end, or nearby, and fragmented (because there is a map).

Or you could just boot PartedMagic and run TestDisk!

Surprisingly, you can recover part of the disk. And if the process is a real format (erases data)
and it does not respond to the frantic presses on the “stop” button, the only recourse is the plug.

Do people actually start a format on a partition with no previous thought at all?