# JMFS Speed



## lillevig (Dec 7, 2010)

I recently had my first opportunity to use JMFS (on a 4-tuner, 500GB Premiere). Worked perfectly so a big thanks to comer. I used USB adapter cables insted of direct connecting to my MB so I expected it to be relatively slow and it finished 500GB in a bit less than 9 1/2 hours. I use Clonezilla to make a periodic clone of my PC hard drive (500GB) and it takes only about a third of that time. Granted, only one of the two drives is tethered via USB, but I wondered about the huge time difference. I also wondered what JMFS does differently than Clonezilla which uses dd as the underlying copy mechanism. I'm sure something is different otherwise folks would just use the dd on the MFS Tools disk to copy Premeire drives. I understand that JMFS would still be needed to do the Expand and Supersize but those are quick on their own. Will someone please help clear up my ignornace?


----------



## vectorcatch (Nov 21, 2008)

The biggest difference is the block size, if I remember correctly jmfs is doing everything in either 512byte or 4k chunks. That means the code reads it and the writes it for each chunk, so there is a ton of overhead. Most modern devices deal internally with much larger block sizes (bandwidth is king over latency here)

Actually if you run the dd part of jmfs manually though the terminal you can control the block size and speed things up significantly.

Typically the block size is small with something like dd if you have a bad drive and you want it to get as much data as possible so you read small chunks, so it won't fails large sections.


----------



## unitron (Apr 28, 2006)

vectorcatch said:


> The biggest difference is the block size, if I remember correctly jmfs is doing everything in either 512byte or 4k chunks. That means the code reads it and the writes it for each chunk, so there is a ton of overhead. Most modern devices deal internally with much larger block sizes (bandwidth is king over latency here)
> 
> Actually if you run the dd part of jmfs manually though the terminal you can control the block size and speed things up significantly.
> 
> Typically the block size is small with something like dd if you have a bad drive and you want it to get as much data as possible so you read small chunks, so it won't fails large sections.


Technically I think that's the

ddrescue

part of jmfs, and not the original

dd

although maybe he included both on the cd, the way MFS Live includes both

dd

and

dd_rescue

(which is not to be confused with

ddrescue

)


----------



## L David Matheny (Jan 29, 2011)

lillevig said:


> I recently had my first opportunity to use JMFS (on a 4-tuner, 500GB Premiere). Worked perfectly so a big thanks to comer. I used USB adapter cables insted of direct connecting to my MB so I expected it to be relatively slow and it finished 500GB in a bit less than 9 1/2 hours. I use Clonezilla to make a periodic clone of my PC hard drive (500GB) and it takes only about a third of that time. Granted, only one of the two drives is tethered via USB, but I wondered about the huge time difference. I also wondered what JMFS does differently than Clonezilla which uses dd as the underlying copy mechanism. I'm sure something is different otherwise folks would just use the dd on the MFS Tools disk to copy Premeire drives. I understand that JMFS would still be needed to do the Expand and Supersize but those are quick on their own. Will someone please help clear up my ignornace?


In this post from earlier this year I mentioned a discrepancy in run times between the ddrescue on the JMFS CD and the version on the Ubuntu Rescue Remix 12.04 CD. You may have encountered something similar. My drives were connected using SATA, however, one directly to the motherboard and one indirectly through an eSATA drive dock.


----------

