Bug 188131

Summary:	Anaconda and kernel daemons spend a lot of time in the D-state syncing
Product:	[Fedora] Fedora	Reporter:	David Howells <dhowells>
Component:	rpm	Assignee:	Panu Matilainen <pmatilai>
Status:	CLOSED INSUFFICIENT_DATA	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	5	Keywords:	FutureFeature
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-03-11 16:54:20 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description David Howells 2006-04-06 10:27:21 UTC

Whilst upgrading my desktop to FC5, I noticed that Anaconda, mdX_raid1 and the  
kjournald daemons spending a _lot_ of time in the D-state.  Attaching strace  
to the installer, I noticed a lot of fsync() or fdatasync() calls being made,  
which would seem to account for this.  
  
Admittedly, the files being installed need to be written, sync'd and then  
moved into place, but couldn't the sync'ing be batched?  Rather than calling  
fsync() or fdatasync() on each file, couldn't anaconda just write all the  
files and then sync() the lot of them, then move them across?  Or maybe it  
could do it in smaller batches. 
 
Also, when anaconda is in the D-state, it can't also be updating its display, 
though that's a minor matter as most people probably won't switch away from 
it.

Comment 1 Jeff Johnson 2006-04-12 17:51:55 UTC

Do you have actual measurements or just anecdotes from watching anaconda installs?

Without actual measurements, it's very hard to say what problem is being solved,
and entirely impossible to guess whthere sync's can be batched or not.

Anaconda not being able to update its display is a very different problem that
needs to be fixed by putting the display on its own thread, with its own cpu
resources, rather than  using cpu cycles from the callback to update the display.
You are correct that there is no reason why rpmlib's D state should prevent
anaconda screen updates. That is an architectural, not implementation, problem.

Comment 2 David Howells 2006-04-12 18:06:47 UTC

> Do you have actual measurements or just anecdotes from watching anaconda  
> installs?  
  
Unfortunately, I wasn't set up to measure anything as I didn't expect this 
problem (it was a one-off upgrade of my desktop box; not something I do 
regularly). 
 
I started investigating why it was being so slow when it proved to be taking 
hours to complete, despite the NFS server being a short distance away. I'll 
see what I can do to reproduce the problem, though I'll have to sort out 
another computer to do it on. 
 
I can probably get strace logs with timestamps from installer processes, but 
I'm not sure what else I can measure. Is there anything you'd care to suggest?

Comment 3 Jeff Johnson 2006-04-13 01:53:10 UTC

Anecdotal and non-reproducible is impossible to fix.

FWIW, rpm has --stats to identify time taken on various operations, all modes.

Comment 5 Red Hat Bugzilla 2007-08-21 05:23:19 UTC

User pnasrat's account has been closed

Comment 6 Panu Matilainen 2007-08-22 06:33:56 UTC

Reassigning to owner after bugzilla made a mess, sorry about the noise...

Comment 7 petrosyan 2008-03-11 16:54:20 UTC

The information we've requested above is required in order
to review this problem report further and diagnose/fix the
issue if it is still present.  Since there have not been any
updates to the report since thirty (30) days or more since we
requested additional information, we're assuming the problem
is either no longer present in the current Fedora release, or
that there is no longer any interest in tracking the problem.

Setting status to "INSUFFICIENT_DATA".  If you still
experience this problem after updating to our latest Fedora
release and can provide the information previously requested, 
please feel free to reopen the bug report.

Thank you in advance.