Fwd: Re: [Patch] dosmode: Compare block devices to detect reparse points
james at et.byu.edu
Wed Dec 5 18:19:09 UTC 2018
Forgot to CC the mailing list. For anyone else listening in.
-------- Forwarded Message --------
Subject: Re: [Patch] dosmode: Compare block devices to detect reparse
Date: Wed, 5 Dec 2018 11:17:53 -0700
From: James Ashdown <james at et.byu.edu>
To: Uri Simchoni <uri at samba.org>
CC: Noel Power <nopower at suse.com>, Jeremy Allison <jra at samba.org>
I was the one who said it, and I think Noel clarified to match what I
meant. As I understand it, the Samba disk free report returns available
units for the path (and therefore, the volume) that the client asks
about. At least some clients, including File Explorer on Windows 10, ask
about the root of the share by default, unless they are given a set bit
for FILE_ATTRIBUTE_REPARSE_POINT to indicate that the status quo has
Windows 10 file servers do handle NTFS symlinks and mountpoints as
reparse points, setting FILE_ATTRIBUTE_REPARSE_POINT for responses to
both Find (SMB2_FIND_ID_BOTH_DIRECTORY_INFO) that mention the crossing,
and for Create requests that specifically target the crossing. The
Windows 10 File Explorer client writes to a mountpoint subdirectory
shared by a Windows 10 file server correctly, but fails with the same
configuration on a Samba server. The client bumps up against a disk
quota that doesn't apply to the actual write destination.
On 12/4/18 15:35, Uri Simchoni wrote:
> Thanks Noel. I figured this is the case, but some of this thread (maybe
> not your words, on second reading) implied that smbd responds according
> to the share's root or volume root. Smbd's responses do reflect the
> available disk space for each path, but some clients assume the disk
> space is the same unless "warned" by a reparse point.
> I suppose my past success with such schemes involved different Windows
> client versions (Win7 or Win8 - can't remember right now).
> On 12/5/18 12:07 AM, Noel Power via samba-technical wrote:
>> On 04/12/2018 18:50, Uri Simchoni wrote:
>>> On 12/4/18 4:48 PM, Noel Power via samba-technical wrote:
>>>> Hi All,
>>>> So probably best first to tell what the current problem is,
>>>> If you have a SAMBA share (where the directory is on device
>>>> /dev/deviceA) and somewhere in the the tree of children you have a
>>>> folder which is a mountpoint to a directory on a different device (e.g.
>>>> /dev/deviceB) then the following happens
>>>> a) The quotas associated with /dev/deviceA are also applied to the
>>>> folders that are located on /dev/deviceB, very annoying if the quota on
>>>> /dev/deviceB hasn't been exceeded and you should still be able to write
>>>> stuff to this device but the quota has been reached on /dev/deviceA so
>>>> you can't :-)
>>>> b) The free space capacity of /dev/deviceA is used throughout the share
>>>> (including those folders located on a difference device) this is of
>>>> course also annoying if the capacity of /dev/deviceA is smaller (or has
>>>> no space left) and there is plenty of space on /dev/deviceB meaning you
>>>> cannot write to folders that are on /dev/deviceB even though there is
>>>> plenty of free capacity
>>> I'm a bit puzzled. Indeed, SMB1 didn't have the capability of querying
>>> disk space relative to a path, and this capability is added in SMB2.
>>> However, we're passing the path from the protocol all the way to
>>> SMB_VFS_DISK_FREE(), and to SMB_VFS_GET_QUOTA(), and in the default
>>> backend we use this path. We have tests for the SMB layer using a custom
>>> VFS module that fakes free disk and quotas.
>>> Back when I was into quotas, I kind-of tested this in the field, but not
>>> using mount points. We used "inherit owner" and in that case, the quota
>>> used for free-disk calculation is that of the owner, because that's the
>>> likeliest user to affect new file's quota. Nevertheless you get the
>>> effect that same user is getting different quotas on different paths,
>>> and, consequently, different free disk space, and it seemed to work.
>>> Without fixing the free-disk query to behave so with relation to
>>> inherit-owner, Windows Explorer would refuse to copy files into the
>>> inherit-owner directories if the user didn't have enough quota, but this
>>> has been fixed long ago and is tested.
>>> The reparse point is probably needed for something, or this wouldn't
>>> have come up, but as long as we try to state the problem clearly - can
>>> you correct me where I'm wrong?
>> The problem isn't to do with the disk free calculation or whether it can
>> deal with different paths, the problem is the windows client only
>> queries the capacity of the root dir of the share.
>> The windows client (I imagine) assumes all child paths are on the same
>> device. The reparse point provides the hint that a directory (either a
>> mountpoint or a dfs link) is a boundry possibly crossing into another
>> filesystem and that is why it's presence will prompt a new capacity
>> query of that path. I can post some traces if that helps
More information about the samba-technical