Bug 755140

Summary: Large amounts of disk I/O on a flash drive makes machine unresponsive
Product: [Fedora] Fedora Reporter: Scott Baker <scott>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-11-23 13:24:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Scott Baker 2011-11-19 00:43:01 UTC 
Description of problem:
When I tried zeroing out a USB Flash drive after a couple of minutes my machine became completely unresponsive. I could move the mouse, and the windows that were animated still moved, but KDE wouldn't accept any input (mouse/keyboard). After the disk I/O stopped the machine was responsive again.

Version-Release number of selected component (if applicable):
Completely up-to-date F16 install

How reproducible:
Easy

Steps to Reproduce:
1. Insert multi-gig USB Flash drive
2. dd if=/dev/zero of=/dev/sdX
  
Actual results:
Flash drive will begin to zero out, and after a minute or so the box will be completely unresponsive.

Expected results:
Box remains responsive and usable during the zero-out process

Additional info:
Also tried it with pv

pv /dev/zero | dd of=/dev/sdX
Comment 1 Scott Baker 2011-11-19 00:49:25 UTC 
I recently upgraded from F14, and did not have this problem.
Comment 2 Scott Baker 2011-11-19 00:51:37 UTC 
Looks like this might be a dupe of:

https://bugzilla.redhat.com/show_bug.cgi?id=734516
or
https://bugzilla.redhat.com/show_bug.cgi?id=721127
Comment 3 Chuck Ebbert 2011-11-23 13:24:10 UTC 

*** This bug has been marked as a duplicate of bug 734516 ***