WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: Defragmenting your boot drive  (Read 4584 times)

Offline adrian

  • Newbie
  • *
  • Posts: 31
Defragmenting your boot drive
« on: June 08, 2012, 12:13:18 PM »
Hi all, I was working on a project to make a tiny virtual server and found that I wanted to defragment my boot drive to minimize the space used by the virtual disk.  So after looking around and experimenting a lot I wrote it down in this utility.

It does a lot in terms of checking stuff, but of course it can't check for everything.

The help is in the header of the file, or just run the utility and it will spit it out too. :)

Hope this helps others.


A

Offline beerstein

  • Hero Member
  • *****
  • Posts: 530
Re: Defragmenting your boot drive
« Reply #1 on: June 09, 2012, 06:30:07 AM »
Hi adrian: I thought linux partitions (formatted with linux file systems) do not need defragmentation.
Could you please explain a bit more? Thank You
t(w)o be(ers) or not t(w)o be(ers) that is the question

Offline adrian

  • Newbie
  • *
  • Posts: 31
Re: Defragmenting your boot drive
« Reply #2 on: June 09, 2012, 09:07:23 PM »
Sure beerstein.

It is true for the most part, that most if not all linux file systems (FSs) do not need defragmentation... mostly.  It is of course possible to fragment one anyway.  You see, the FSs doesn't really move stuff around, mostly due to reduction of write speed IIRC.  It just tried to preallocate contiguous blocks. Thus, when you create a few files, delete a subset of those files, you create holes in the allocated space.  If the FS can, it will either not allocate a new file that cannot fit in to those holes or if there is no space left, will allocate across multiple holes.  I'm not currently aware of reallocation systems built in to the FSs.  Though I have heard of a few tools.  A few examples can be found  here on this wiki.  To find out the state of your disk, you can use fsck, but mind you, it needs to either be unmounted or mounted as read only.

Even if the files are not fragmented, there will be a bunch of holes in the FS.  The tool I made was mainly due to me wanting a super small dynamic .vdi file (VirtualBox virtual disk).  For a dynamic disk, any cluster that is just a bunch of zeros will not be allocated.  If you have a bunch of non contiguous clusters, there is overhead to specify where the non-contiguous actual data is located on the drive.  The more non-contiguous blocks, the more overhead.

Using this script, I dropped a 97MB .vdi file to 72MB.  This probably doesn't mean much to most people, but it did for me, so I figure there are others out there who it might also be of use to.

If you are not using a virtual disk or are using a non-mechanical medium, it probably won't be useful at all.  Nor if you put your extensions on another device, since assuming there is no boot stuff on that device, the extra stuff I'm managing with my tool is not going to be needed.

Further, fragmentation would only occur on a drive you are constantly creating and deleting files on, and usually (but not necessarily) only when the drive is getting near capacity.  It might make the tiniest of difference in a mechanical medium if your drive is small and you keep putting on and taking off extensions on the boot partition, in which case, this may be useful to copy your drive to another medium using this tool, booting off the new medium and then copying it back.

If fragmentation is a problem on a non-boot drive, either use the tools out there or get another device that you can move your files to.  Moving the files to an empty device will force the data to be stored in a contiguous fashion.

I hope I've answered your question.  If not, feel free to ask more. :)


A