tech-kern archive

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

Re: vnode_has_large_blocks() (vnd.c rev 1.255)



bouyer%antioche.eu.org@localhost (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 called on sc_vp, that's the vnode opened for the backing store.

The vnd geometry is read directly from sc_geom which is initialized
in the VNDIOCSET code before the thread is started.

So I don't think the check is done too early.


>> But if the I/O request is smaller, it would fail. The vnode_has_large_blocks
>> validates that this may happen and configures vnd to fall back to the
>> slower method. This happens when the backing store is e.g. on a 4k/sector
>> disk and the vnd device simulates a 512byte/sector disk.

>OK, I though this would be the filesystem block or fragment size.

Yes, the I/O size of the backing store in case of FFS is the
fragment size. The minimum fragment size is the sector size. So on
the 4k/sector disk the fragments are always 4k or larger.

Saying this, I'm not sure if the large blocks check isn't too aggressive.

Obviously it is needed to prevent I/O requests smaller than the sector
size, and that's why the check was added. I think that anything smaller
than the fragment size is forbidden too to avoid buffer corruption,
but is that really true? The backing filesystem will never do I/O smaller
than the fragment size.

-- 
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."


Home | Main Index | Thread Index | Old Index