[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: assumption about a device's maxphys
On Tue, Oct 09, 2012 at 06:16:44PM -0700, Chuck Silvers wrote:
> hi thor,
> your tls-maxphys branch appears to assume that a given device's maxphys is
> but consider the case of a software "device" like a logical volume from LVM.
> one very nice feature of a volume manager that I used to work with (veritas
> is that it can migrate a volume to new storage on the fly, while the data in
> is being read and written. with such a virtual device, I assume that
> would be that the maxphys of the volume would be the same as the maxphys of
> underlying physical device, but the maxphys of the underlying physical device
> could be different before and after a volume migration, so that doesn't fit
> very well with the assumption that a device's maxphys doesn't change.
> caching "the" device maxphys in a file system's "struct mount" is also
> since a file system may directly access multiple underlying devices, as ZFS
> and those devices may each have a different maxphys.
> could you think about how to enhance the new maxphys design to accomodate
> these cases?
There's another case, which I think is worse: a raidframe volume, with
underlying disks with different maxphys. If it's a raid-1 you can't predict
from which disk a read will come from, so you don't know the maxphys.
I wouldn't expect this case (a volume composed of multiple disks with
different maxphys) to be that common, so I'm not sure we should optimise
for this. The volume's maxphys would be the lower of all the devices's
A tricky case is when the new maxphys would be smaller. You would need
to suspend filesystemm operations before changing it, but I'm not sure
all filesystems support this. Maybe support for splitting the request in
VOP_STRATEGY() or another appropriate place would be better ?
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
NetBSD: 26 ans d'experience feront toujours la difference
Main Index |
Thread Index |