Re: assumption about a device's maxphys

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Tue, Oct 09, 2012 at 06:16:44PM -0700, Chuck Silvers wrote:
> 
> caching "the" device maxphys in a file system's "struct mount" is also
> problematic since a file system may directly access multiple underlying
> devices, as ZFS does, and those devices may each have a different maxphys.

I did think about this at some length.  But our kernel is shot through with
assumptions that a filesystem lives on a single device, not just where I/O
is dispatched but in the mount path and elsewhere.  The only short path
forward would seem to be virtual devices that homogenize the view of such
things -- and isn't this, actually, what our ZFS implementation does?  A
zpool is a single device, not many, no?  Doesn't even Solaris do this?

I also do not believe it is appropriate for the upper layers (the physio
code, the pager code, etc.) to have to reach down into the filesystem code
to understand what size I/O they may do on a per-vnode basis -- or, worse,
on a per-vnode, per-offset basis.  Per-vnode we could accomplish by moving
the maxphys value from the mount entry to the vnode, perhaps defaulting it
from the mount entry at vnode creation time if the filesystem does not want
to do something more sophisticated, but what if half of a file is on device
X and half on device Y?  I believe the lower layers should hide these things
and that at some point a single, consistent value should be presented over
a larger collection of objects.  I believe the filesystem is the most
convenient such collection.

Thor