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