Re: assumption about a device's maxphys

[Adam Hamsik <haaaad%gmail.com@localhost>]

On Oct,Wednesday 10 2012, at 2:46 PM, Thor Lancelot Simon 
<tls%panix.com@localhost> wrote:

> 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?

Situation like this is quite common even for LVM where after resize added 
chunk of disk space may resides on other disk which might have different 
maxphys.

> 
> 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

Regards

Adam.