Disk access locking whole PC

12.04 lts, if it's not clear.

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/999386/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

Find right package says I should use 'ubuntu-bug storage' to classify it, though so far as I can tell that is not actually possible. I also have no idea what "Use Storage Symptom standard reply" is.

You are mentioning Virtualbox in your report... What is your host OS, and is Ubuntu the guest?

If you use large files regularly, you may want to read filesystem benchmarks such as http://www.phoronix.com/scan.php?page=article&item=ubuntu_1204_fs&num=1
In my experience (single hard drive) the xfs filesystem worked the best for large files, ext4 is "OK", while ext3 and reiserfs are very slow.

Ubuntu is the host, Windows 7 is a virtualized guest.

Using the Phoronix test suite to do FS benchmarks is a good idea, I'll give that a go when I'm back at work on Monday.

Thank you for the information. Since Ubuntu is the host, this may have something to do with kernel, but they'll need logs during or after a large file transfer that you perform to be able to debug. Please run the following command (during or after your filesystem stress test) which will attach necessary information:

  apport-collect 999386

When I try the above it just says 'No additional information collected' and quits.

Possibly because there hasn't actually been a crash to trigger it?

I'm going to try finding the PTS file systems tests and running them now.

I found a bug report upstream (Linux kernel) that has the same symptoms to your issue. May you review it, and if you believe this is the same problem you have, I can link the two reports:

"Large I/O operations result in poor interactive performance and high iowait times"
https://bugzilla.kernel.org/show_bug.cgi?id=12309

http://openbenchmarking.org/result/1205228-BY-FILESYSTE76

No idea if they're reasonable results or not, but they don't seem crazy. My sytem didn't seem to lock when I ran them, though I was gone for most of it.

The bug you posted seems to describe similar symptoms.

I think my issues are also much much much worse if there is concurrent large disk activity. Like copying 1 file while doing db operations, vs doing either one without the other going on.

For example, copying a file while doing a sphinx index or running some mysql queries locks most gui apps until one of the two processes is done.

(Whereas, just copying a file only locks stuff some of the time, and usually more intermittently.)

I have also faced this issue while copying the files from one external HDD to another. Typical transfer size is in range of 20-40 GBs.