[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] new knob to tweak caching mode for backends



Olaf Hering writes ("Re: [Xen-devel] new knob to tweak caching mode for 
backends"):
> On Tue, May 27, Stefano Stabellini wrote:
> > So I think that as long as we keep the default behaviour sane, we can
> > expose whatever advanced options we like.
> 
> Its not about changing defaults, but rather provide knobs for the new
> features. Now that the backend is qdisk

Your ideas seem to be based on the idea that the backend is always
qdisk, but that's not true.  blkback is stil in use, and we still
probably have some tapdisk users.

> So with this in mind, will a patch be accepted to add some sort of
> "char *cache" member to struct libxl_disk_device? Should it accept all
> values libvirt and qemu knows about, or just the few values qdisk can
> actually handle (nocache|write-back|directsync)?

Certainly it should not be a char*.  It should be a defbool, or an
enum with a default value.

The basis for deciding what values to provide should be to consider
what different values might be supported which would correspond to
usefully different behaviours.

Also, we have to decide what should happen when the backend doesn't
support the requested caching mode.  The normal libxl behaviour would
be to fail.  That means that the libxl needs enough knowledge to
negotiate with the underlying layers about these options.

> In addition to that: the direct-io-safe knob does not only enable AIO it
> also changes from write-back to directsync. Qemu has a knob aio=native
> and cache= for directsync. Looks like direct-io-safe merges both. Is
> that intentional? If libxl gets a cache= option, should it be possible
> to specify "direct-io-safe,cache=write-back"?

direct-io-safe is a hack to work around a bug.  At the moment, doing
direct io in qemu is not safe because of bugs in some underlying
filesystems.  When direct-io-safe is not specified, we should never
arrange for qemu to use O_DIRECT.

So it might be that someone who uses your new caching option will have
to specify direct-io-safe as well as the caching option which implies
O_DIRECT.  Without direct-io-safe, libxl ought to say "you have asked
for something which implies O_DIRECT but this is not known to be safe
due filesystem bugs".

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.