On Sun, Sep 09, 2018 at 05:15:07PM +0200, Michael van Elst wrote:
> The handle_with_rdwr code does lots of weird things.
I've committed a few changes and behaviour is now more reasonable.
Can you test this in a real setup?
--
Michael van Elst
Internet: mlel...@s
On Sun, Sep 09, 2018 at 03:00:11PM +0200, Manuel Bouyer wrote:
> > I'm doing some benchmarks now (just for vnd, not xen yet). I can see
> > a penalty of about a factor of 2 for linear I/O, much less for random I/O.
>
> On my setup it's between 5 and 10. enough to make the disks 100% busy
> with l
On Sun, Sep 09, 2018 at 11:49:20AM -, Michael van Elst wrote:
> bou...@antioche.eu.org (Manuel Bouyer) writes:
>
> >I strongly dissagree. I have 512-byte-sectors domUs running for years on a
> >dom0 with 64k blocks/8k fragements. This works ! I'm I'm probably not the
> >only one, as this has b
bou...@antioche.eu.org (Manuel Bouyer) writes:
>I strongly dissagree. I have 512-byte-sectors domUs running for years on a
>dom0 with 64k blocks/8k fragements. This works ! I'm I'm probably not the
>only one, as this has been this way since we have dom0 support.
>It's very unlikely that others hav
On Sun, Sep 09, 2018 at 10:15:20AM -, Michael van Elst wrote:
> I'm about to commit a change that uses mnt_stat.f_iosize instead. For
> backing store on FFS that at least allows the faster method for virtual
> disks with sectors of at least the fragment size, and I don't think we
> can safely d
mlel...@serpens.de (Michael van Elst) writes:
>>AFAIK getdisksize() returns the parameters of the vnd device, not the
>>backing store.
>It's called on sc_vp, that's the vnode opened for the backing store.
And that is the problem. The VREG vnode doesn't implement the disk ioctls
necessary to make
On Fri, Sep 07, 2018 at 01:18:40AM +, m...@netbsd.org wrote:
> is xen suspend resume really handled with zero notifications for the
> running kernel?
> and all this work for a feature that I hear netbsd doesn't even support?
I don't understand your question, sorry. How is the discussion about
is xen suspend resume really handled with zero notifications for the
running kernel?
and all this work for a feature that I hear netbsd doesn't even support?
On Thu, Sep 06, 2018 at 10:40:37AM +0200, Michael van Elst wrote:
> On Thu, Sep 06, 2018 at 10:09:35AM +0200, Manuel Bouyer wrote:
>
> > but that's not going to change. If you move a virtual machine from a 512b
> > to a 4k sector disk, you expect the virtual machine to still run.
> > If you change
On Thu, Sep 06, 2018 at 10:09:35AM +0200, Manuel Bouyer wrote:
> but that's not going to change. If you move a virtual machine from a 512b
> to a 4k sector disk, you expect the virtual machine to still run.
> If you change the virtual's disk sector size its filesystems will
> probably be unusable.
On Thu, Sep 06, 2018 at 06:46:12AM -, Michael van Elst wrote:
> bou...@antioche.eu.org (Manuel Bouyer) writes:
>
> >thinking about it more, I think this is the wrong approach. For example,
> >if the vnd is for a linux domU, getdisksize() won't return anything
> >usefull, but the I/O will proba
bou...@antioche.eu.org (Manuel Bouyer) writes:
>thinking about it more, I think this is the wrong approach. For example,
>if the vnd is for a linux domU, getdisksize() won't return anything
>usefull, but the I/O will probably be 4k-compatible. Even for a NetBSD domU,
>as the xbd protocol uses 512-
bou...@antioche.eu.org (Manuel Bouyer) writes:
>But in any case, the code as is is wrong, and always ends up using
>vnrdwr().
I can at least confirm that it doesn't work as intended.
vnd1 disk1 b3daaac8 b6a50c08
crash> x/x b6a50c08
b6a50c08: b3daa
bou...@antioche.eu.org (Manuel Bouyer) writes:
>> The backing store and the geometry are initialized before vndthread
>> is started, getdisksize() shouldn't fail and I'm sure it didn't
>> at that time.
>AFAIK getdisksize() returns the parameters of the vnd device, not the
>backing store.
It's ca
On Wed, Sep 05, 2018 at 11:27:51PM +0200, Manuel Bouyer wrote:
> > The backing store and the geometry are initialized before vndthread
> > is started, getdisksize() shouldn't fail and I'm sure it didn't
> > at that time.
>
> AFAIK getdisksize() returns the parameters of the vnd device, not the
> b
On Wed, Sep 05, 2018 at 08:28:27PM -, Michael van Elst wrote:
> bou...@antioche.eu.org (Manuel Bouyer) writes:
>
> >Hello,
> >in vnd.c rev 1.255, vnode_has_large_blocks() has been introduced, and
> >will cause vnd to use VOP_READ/VOP_WRITE instead of VOP_BMAP/VOP_STRATEGY
> >if it returns true
bou...@antioche.eu.org (Manuel Bouyer) writes:
>Hello,
>in vnd.c rev 1.255, vnode_has_large_blocks() has been introduced, and
>will cause vnd to use VOP_READ/VOP_WRITE instead of VOP_BMAP/VOP_STRATEGY
>if it returns true. The commit message was:
>Fall back to VOP_READ/VOP_WRITE if the simulated di
Hello,
in vnd.c rev 1.255, vnode_has_large_blocks() has been introduced, and
will cause vnd to use VOP_READ/VOP_WRITE instead of VOP_BMAP/VOP_STRATEGY
if it returns true. The commit message was:
Fall back to VOP_READ/VOP_WRITE if the simulated disk has smaller
sectors than the underlying filesystem
18 matches
Mail list logo
