Home > Uncategorised > What Happened When I Defragmented my Media Centre

What Happened When I Defragmented my Media Centre

October 15th, 2008 Leave a comment Go to comments

So this is now post number four in a long rambling series on how to stop my media centre from taking forever to delete a recording.

Last time, I spoke about the theory of how to defragment a particular set of files on a Linux partition. In my case, this is ext3, but the theory applies across the board and even works for Windows NTFS partitions as well.

Anyway, this is how I have defragmented my recordings….

I am in the lucky situation that I had two hard drives in my media centre, and luckily I also had enough free space on the “other drive” (the one that doesn’t contain the recordings) to hold all of the recording files in one go. To make life easier, on the destination drive, I created a directory: /home/defrag.

I then changed into my recordings directory, and issued the following command:

find . -mtime +1 -exec mv {} /home/defrag/ \;

This will move all files older than 24 hours into the directory /home/defrag. As I said previously, you will note that I am doing this using “mv” and not “cp” in order to guarantee that I’m defragmenting the files as I go.

I then left this for blood ages to copy the files to the other drive. That part has just finished, and I will shortly move them back to their original locations. Therefore, they should be nicely defragmented.

Now, there are a couple of things to note with this:

  1. MythTV doesn’t like it if you remove the recordings from underneath it’s feet. Thinking about it, that kind of makes sense, so make sure you have the MythTV backend disabled, and it’s not recording anything. Hopefully mine will be fine once I have restored the files, and rebooted!
  2. That “24 hours” clause on the find command is there for a reason. It means that it won’t move anything that is currently being recorded. Although, if you have the backend turned off, then you shouldn’t need to worry about that anyway.
  3. The files were not moved in the order that I was expecting. Now this, for me, is the most interesting point. When the files were moving, they appeared to be moved in a completely random order – it was not by date/time, nor was it alphabetically. It jumped from letter to letter, from month to month. Now, I expect that this is because the files are being read in disk order – i.e. the order that they are stored on disk. I’m trying to find a reference for “find”, but I cannot seem to find one that says what the default sort order is – I expect it’s probably “no sort”, as in, handle the files as they are encountered. What this means is, if the files are being read in from disk, and are jumping around from month to month, it therefore means that the free space between recordings has been reused, and therefore you are quite likely to get fragmentation occurring.

Bingo! So, if they are being retrieved in the order that they are on disk, and that order is strange, then something is probably fragmented somewhere. Also, when you couple this with the fact that one of the recordings is the 5 hour long Beijing Olympic Opening Ceremony (a hefty 12GB in size), it’s quite plain to see that may be it was pretty well fragmented around that part of the disk. 165GB of semi-fragmented files is not going to be particularly responsive.

I feel somewhat vindicated….

Anyway, once everything is back in place, I’ll provide an update as well. I’m also planning on doing the other suggested things, like really pruning down the “Record All Showings” schedules that I have, and then running the database optimisation script as well. After each one, I’ll make some notes, so I can nail down precisely what causes the problem.

Categories: Uncategorised Tags:
  1. No comments yet.
  1. No trackbacks yet.