Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 451738 - kcryptd I/O blockage using encrypted filesystem on LVM
Summary: kcryptd I/O blockage using encrypted filesystem on LVM
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 9
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Milan Broz
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-06-17 01:34 UTC by Michael Hampton
Modified: 2013-03-01 04:06 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-08-26 11:13:14 UTC

Attachments (Terms of Use)

Description Michael Hampton 2008-06-17 01:34:01 UTC
Description of problem:
When using an encrypted filesystem on LVM, whether an encrypted PV or LV, the
kernel frequently blocks for long periods of time waiting for I/O. top shows
anywhere from 20% to 100% CPU time waiting for I/O. Affected processes freeze
for several seconds, up to a minute or more, waiting for even small disk

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Install Fedora 9 to encrypted PV.
2. Use moderately disk intensive processes such as firefox, thunderbird or liferea.
Actual results:
Some disk operations take dozens of seconds to complete.

Expected results:
Disk operations should complete in a reasonable time.

Additional info:
Issue did not occur with Fedora 8. Help tracking this down would be greatly

Comment 1 Dave Jones 2008-06-17 01:45:54 UTC
this is likely another case of the 'firefox fsyncs too much' bug.  (it calls
fsync every time it updates the history db - ie, each time you view a new page.
unfortunatly fsync on ext3 means 'write everything in memory out to disk, not
just the data from this process'.

Comment 2 Milan Broz 2008-07-04 16:32:29 UTC
There is commit in 2.6.26 kernel (adding cond_resched()) in dmcrypt code, which
should help in this situation.
(System still need wait for io to finish, but other running application should
be more responsible.)

Comment 3 Milan Broz 2008-08-26 11:13:14 UTC
cond_resched() call is in 2.6.26+ kernels, it should help in some situations.

There are still some situations when system will wait for IO - mainly if you have multiple LVs but only one encrypted PV...

closing this rahwide, there is already kernel with this patch.

Note You need to log in before you can comment on or make changes to this bug.