From: Blaisorblade <blaisorblade@yahoo.it>
To: user-mode-linux-devel@lists.sourceforge.net
Cc: Gerhard Hannemann <gerhard.hannemann@printsoft.com>
Subject: Re: [uml-devel] UML - stalling during large file transfers
Date: Fri, 21 Jan 2005 12:55:59 +0100 [thread overview]
Message-ID: <200501211255.59809.blaisorblade@yahoo.it> (raw)
In-Reply-To: <41F0A696.8050201@printsoft.com>
On Friday 21 January 2005 07:52, Gerhard Hannemann wrote:
> Encountered a baffling problem while copying large amounts of files from
> a archive (*.tbz) or from a remote system to a directory within a
> running UML system. The UML stalls while the IDE hardrive thrashes along
> for server minutes. It recovers, continues on with some more files, and
> stall again. While this is happening, all maternity's connected to that
> UML just freeze.
> The host system is perfectly accessible and on show minimal CPU usages.
> A running top session within the UML also show low CPU and moderate
> memory usage. However the UML's load increases up to 3.x for several
> minutes and then recovers.
> System Data:
>
> Host:
> AMD Athlon 2.1Ghz running Gentoo using 2.6.9 kernel with skas3 patch.
> 1 SCSI 18G drive (boot drive) and one IDE 15G drive.
> 1G tmpfs
> UML:
> Vanilla 2.4.27 UML kernel (patched of UML usage)
> 3G file system and 512M swap.
> The UML is run using 512M of mem.
> The UML runs from the IDE drive.
I've just read the beginning, however I suspect you are running a
not-up-to-date UML with the kernel option "CONFIG_BLK_DEV_UBD_SYNC" or the
option "ubd=sync" on the command line. Until a little time ago, that meaned
that the write requests (which are synchronous) were executed by the UML
kernel and not by the separate thread used normally.
The workaround is to recompile disabling that option, and adding for each UBD
the 's' option (i.e. ubd0= becomes ubd0s= and so on). So, you still get the
safety without the slowdown.
This workaround is not needed in recent UML versions (for instance 2.6.9-bs5
is surely ok, I don't remember if stock 2.6.9 already has the fix). The fix
has not yet been backported to 2.4 (although it's easy).
--
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
prev parent reply other threads:[~2005-01-21 11:43 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-21 6:52 [uml-devel] UML - stalling during large file transfers Gerhard Hannemann
2005-01-21 11:55 ` Blaisorblade [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200501211255.59809.blaisorblade@yahoo.it \
--to=blaisorblade@yahoo.it \
--cc=gerhard.hannemann@printsoft.com \
--cc=user-mode-linux-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox