Disk access locking whole PC

[Slogger]

Using a quad core i5 with 8 gigs ram and 2 terabyte HD, cleanly formatted as ext4 at install.

Commands which alter or move large files lock the whole system such that web browsers, system monitor, IM, etc. become non-responsive and gray out.

Typical scenarios:
Create a new VirtualBox vm and preallocate 10 or 60 gigs.
Or take a large file large.f several gigs in size and small file small.f any size and execute "cat large.f >> small.f"
or take large dot-gz file large.gz of several gigs in size and run "gzip -d large.gz".

I've done these kind of commands previously in VMs and not had the whole system lock up, but now the system is pretty much completely unuseable until these kind of commands complete. I've got no idea why, but it seems pretty clear that intensive disk access is somehow locking the system.

I'm not really sure what info would be useful with this, but if there's any sort of diagnostic I can run, or log that'd be helpful, let me know.

[Slogger (slogger)]

12.04 lts, if it's not clear.

[Ubuntu Foundations Team Bug Bot (crichton)]

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.]

[Slogger (slogger)]

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.

[Patrick Santos (milljudgement+ubuntu)]

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.

[Slogger (slogger)]

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.

[Patrick Santos (milljudgement+ubuntu)]

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

[Slogger (slogger)]

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.

[Patrick Santos (milljudgement+ubuntu)]

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

[Slogger (slogger)]

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.

[Slogger (slogger)]

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

[Kranti Agrawal (krantionline)]

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.