From: Jeff Dike <jdike@addtoit.com>
To: Blaisorblade <blaisorblade@yahoo.it>
Cc: user-mode-linux-devel@lists.sourceforge.net,
Bodo Stroesser <bstroesser@fujitsu-siemens.com>
Subject: Re: [uml-devel] Review needed for ubd fixes
Date: Wed, 21 Sep 2005 14:04:36 -0400 [thread overview]
Message-ID: <20050921180436.GA7712@ccure.user-mode-linux.org> (raw)
In-Reply-To: <200509211749.46125.blaisorblade@yahoo.it>
On Wed, Sep 21, 2005 at 05:49:43PM +0200, Blaisorblade wrote:
> Since you're going to possibly sleep, it's better to allow kmalloc to sleep in
> first place!
WRONG! The first request in line can't sleep, that's the whole point.
If it does, the system can deadlock. Subsequent requests can sleep, waiting
for previous ones to finish, but there absolutely can't be any sleeping
in kmalloc.
> Is the COW bitmap mmap'ed? Because otherwise we'd need to queue up an
> additional write request, which creates problems.
No. That creates ordering problems which I haven't thought about yet, It
may be worth doing, but explicit writes make ordering easier to think about.
>
> Btw, msync() allows sync'ing only a specific region, which fsync() doesn't
> allow. Don't know whether we need this really, however (we probably don't do
> it, but we should).
Or, the host may just flush out the mmapped stuff on its own. This is my
concern about ordering.
> Also, I kept forgetting to mention one thing: Device mapper has the support
> for COW volumes, like we do. E.g. when you create a snapshot, it is not a
> static immutable copy of the original, it's writable too!
Yeah, that's something to think about.
> Don't think it's reasonable to expect this. I think that filesystems like ext2
> will never produce write barriers - they are needed for journaled FS's.
I thought your point was to rely on the block layer to order overlapping
writes for us.
It sounded reasonable to me :-)
Jeff
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
next prev parent reply other threads:[~2005-09-21 18:28 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-17 22:45 [uml-devel] Review needed for ubd fixes Jeff Dike
2005-09-20 12:01 ` Blaisorblade
2005-09-20 19:06 ` Jeff Dike
2005-09-21 15:49 ` Blaisorblade
2005-09-21 18:04 ` Jeff Dike [this message]
2005-09-21 19:06 ` Blaisorblade
2005-09-21 20:45 ` Jeff Dike
2005-09-22 20:51 ` Blaisorblade
2005-09-27 18:12 ` Jeff Dike
2005-09-28 12:14 ` Blaisorblade
2005-09-28 15:54 ` Jeff Dike
2005-09-28 16:47 ` Blaisorblade
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=20050921180436.GA7712@ccure.user-mode-linux.org \
--to=jdike@addtoit.com \
--cc=blaisorblade@yahoo.it \
--cc=bstroesser@fujitsu-siemens.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