qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Lieven <pl@kamp.de>
To: Marcus <shadowsor@gmail.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	Stefan Hajnoczi <stefanha@gmail.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] qemu-img convert cache mode for source
Date: Wed, 05 Mar 2014 19:09:13 +0100	[thread overview]
Message-ID: <53176849.10804@kamp.de> (raw)
In-Reply-To: <CALFpzo4CQ0tjht-B=mXEY2xwTkkiVVzj2s_wqcEikOKd5DN-uQ@mail.gmail.com>

Am 05.03.2014 18:38, schrieb Marcus:
> On Wed, Mar 5, 2014 at 8:53 AM, Peter Lieven <pl@kamp.de> wrote:
>> Am 05.03.2014 16:20, schrieb Marcus:
>>> I think this is a more generic sysadmin problem.  I've seen the same
>>> thing in the past with simply snapshotting a logical volume or zfs
>>> zvol and copying it off somewhere. Page cache bloats, the system
>>> starts swapping. To avoid it, we wrote a small C program that calls
>>> FADV_DONTNEED on a file, and fork off a process to call it on the
>>> source file every X seconds in our backup scripts.
>> I do not call FADV_DONTNEED on the whole file, but only
>> on the block that has just been read.
> Yes, I suppose that's one of the advantages of having it integrated
> into the reader.
>
>>> It's a little strange to me to have qemu-img do this, just like it
>>> would be strange if 'cp' did it, but I can see it as a very useful
>>> shortcut if it's an optional flag.  qemu-img to me is just an admin
>>> tool, and the admin should decide if they want their tool's reads
>>> cached.  Some additional things that come to mind:
>>>
>>> * If you are running qemu-img on a running VM's source file,
>>> FADV_DONTNEED may ruin the cache you wanted if the VM is not running
>>> cache=none.
>> You would normally not run it on the source directly. In my case
>> I run it on a snapshot of an logical volume, but I see your point.
> Totally depends on the situation, just thought it was worth consideration.
Yes, and it was a good remark.
>
>> So you can confirm my oberservations and would be happy if
>> this behaviour could be toggled with a cmdline switch?
> Yes, I've seen the same behavior you mention just with 'cp'. It was
> with a version of the CentOS 6.2 kernel, at least, before we added
> FADV_DONTNEED into the backup scripts.
Ok, Stefan would you be happy with it?
>
>>> * O_DIRECT I think will cause unexpected problems, for example the
>>> zfsonlinux guys (and tmpfs as mentioned) don't yet support it. If it
>>> is used, there has to be a fallback or a way to turn it off.
>> I don't use O_DIRECT. Its an option for the destination file only at the
>> moment. You can set it with -t none as qemu-img argument.
> I just mentioned it because setting it on the source was suggested
> originally and subsequently discussed.
Yes, but it would break readahead and would not work and tmpfs
and many other things we don't see know.

Peter

  reply	other threads:[~2014-03-05 18:09 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-26 10:14 [Qemu-devel] qemu-img convert cache mode for source Peter Lieven
2014-02-26 15:41 ` Stefan Hajnoczi
2014-02-26 15:54   ` Eric Blake
2014-02-26 16:01   ` Peter Lieven
2014-02-27  8:57     ` Stefan Hajnoczi
2014-02-28 14:35       ` Peter Lieven
2014-03-03 10:38         ` Kevin Wolf
2014-03-03 11:20           ` Peter Lieven
2014-03-03 12:59             ` Paolo Bonzini
2014-03-03 13:07               ` Peter Lieven
2014-03-03 12:03         ` Stefan Hajnoczi
2014-03-03 12:20           ` Peter Lieven
2014-03-04  9:24             ` Stefan Hajnoczi
2014-03-05 14:44               ` Peter Lieven
2014-03-05 15:20                 ` Marcus
2014-03-05 15:53                   ` Peter Lieven
2014-03-05 17:38                     ` Marcus
2014-03-05 18:09                       ` Peter Lieven [this message]
2014-03-06 10:41                         ` Stefan Hajnoczi
2014-03-06 18:58                           ` Peter Lieven
2014-03-06 10:29                 ` Stefan Hajnoczi
2014-03-06 11:29                   ` Paolo Bonzini
2014-03-06 14:19                     ` Liguori, Anthony
2014-03-06 18:07                       ` Peter Lieven
2014-03-07  8:03                       ` Peter Lieven
2014-02-27  1:10   ` Fam Zheng
2014-02-27 11:07     ` Kevin Wolf
2014-02-27 16:12       ` Peter Lieven
2014-03-03 10:40         ` Kevin Wolf

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=53176849.10804@kamp.de \
    --to=pl@kamp.de \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=shadowsor@gmail.com \
    --cc=stefanha@gmail.com \
    --cc=stefanha@redhat.com \
    /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;
as well as URLs for NNTP newsgroup(s).