7Zip Extract progressively slow

[Nunnbt473]

I am on Win 7 Home Preium SP1 x64 and using the Universal Multiboot Installer. I added several ISO files using YUMI to create install/live boots version of OS and anti virus tools on a 128 GB jump drive.

However, when adding Deft 8.2 it dropped from hundereds or thousands of KB/sec to about 132kb/sec. Or so it claims, the overall file progresses at about 1MB/Hour. Then roughly every 30 minutes there after it dropped by 1 KB/sec. Now a 3GB+ file has all of 50MB left and is taking 11 1/2 hours (and still counting) to finish extraction when it should have taken roughly 4. I say 4H based on several other ISO OS I was installing around 1/2 GB to 1.0 GB

I have tried setting Yumi and 7zip to normal and high and realtime priorities but it had no effect on the speed. The system in question is using roughly 5% system resources with over 95-98% idle. I have 8GM of ram, of which 50% is free. The CPU an i7 and everything else runs fine. I even went as far as uninstalling my antivirus. Everything else on the system runs full speed and flawlessly. All drivers and bios..etc are update to date.

Any explanations for why the speed would steadily drop as the extraction process continues?

[Shell]

What exactly is done slowly? You mention extraction of a 3GB+ file (I suppose it is an ISO), but it surprises me - some boot loaders mount ISO files directly. What media it is extracted onto, USB stick? Perhaps, you have a faulty drive and thus media access errors slow down the process.

[Igor Pavlov]

It wasn't slow. It just hanged by some reason. The speed numbers are just average speed.

[Nunnbt473]

Yes the extraction from the 3.0+GB ISO to create a bootable OS on a jumpdrive is insanely slow.

I suppose its possible its a faulty USB, its fairly new which I recently ordered for this purpose. However, the format process before this didn't cause any errors or problems. After 26 hours the system went into stand by causing an error in the copy process.

As for it being hung, I could see where from hour to hour it would occasionally change which XML file it was actively working on. Though XML files are typically quite small and should only take a fraction of a second. I was wondering if there is perhaps some type of memory or restriction with file sizes or something along those lines that might cause this?

--

After it errored out, YUMI removed the failed files and fixed the boot menu automatically. I then ran a 500~ MB ISO file to add to the jump boot. It added it at aprox 2000+ kb/sec and was done in less than 4 minutes.

[Shell]

If your drive is a hard drive (i.e. not a simple USB stick), you should probably check its S.M.A.R.T. data. It will likely show whether the drive is faulty and how much. Drive errors are also recorded in Windows event log.

If the drive is formatted with any FAT file system (with the possible exception of exFAT), then writing a huge number of files will be slow. FAT also imposes restrictions of 4GB per file and about 64K files in a directory. However, I think that it was a drive error in your case.