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 the virtual's disk sector size its filesystems will > > probably be unusable. > > Actually, I wouldn't expect this if the backing store is really a device. > Using a file as a backing store obviously is different and the filesystem > abstraction is supposed to handle this, but it may cost performance. > > But that could be solved by making xbd pass through the geometry. If > a vnd is used as backing store, the geometry can still be simulated.
I think on linux the problem is handled in the dom0 kernel, whatever backing store is in use. We have to stay compatible with linux. > > > Hum, in this case, sc_geom contains what was set at VNDIOCSET time isn't it > > ? > > Yes, that's how the virtual geometry is set. > > > > Unless we provided a geometry at vnconfig time, it'll always have 512b > > sectors. This is not read from the vnd's disklabel. > > Yes. Obviously the vnd's disklabel must be consistent with the vnd > geometry. for the size I agreee. But for sector size we can't expect this. Especially if you move the file from one disk to another. > > > > Sure but that doens't seems to be a problem. the backing filesystem > > is 64k/8k, yet I can use filesystems with smaller fragments in the domUs, > > without problems. It looks like VOP_BMAP/VOP_STRATEGY deals with it > > (actually I think it's write only the relevant physical sectors, even if > > that's not a full fragment, because that's how nbp is set up). > > The filesystem itself only does I/O in terms of fragment sized blocks (or > multiples). I'm not sure how far VOP_BMAP/VOP_STRATEGY work if you do > smaller I/O requests, in particular when you access the same offset with > different block sizes. The buffer cache only matches the offset and > assumes that a "block" in memory has always a specific size. > So while reading or writing through vnd might work with such a partial > block (if still as large as a physical sector), it will at least > corrupt I/O when done on the file itself. This setup is running since netbsd-6 was branched, if not older ... I've never had any corruption issue. -- Manuel Bouyer <[email protected]> NetBSD: 26 ans d'experience feront toujours la difference --
