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
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
