[Patch] dosmode: Compare block devices to detect reparse points

[James Ashdown]

On 12/4/18 07:48, Noel Power wrote:
> On 03/12/2018 20:22, Jeremy Allison via samba-technical wrote:
>> On Mon, Dec 03, 2018 at 01:11:38PM -0700, James Ashdown via 
>> samba-technical wrote:
>>> Flagging each volume crossing (mountpoints and wide links) as 
>>> reparse points
>>> enables correct quota reporting for the actual write destination. 
>>> The flag
>>> is set by checking whether each directory has a different device ID 
>>> (using
>>> smb_filename->st.st_ex_dev) than its parent directory.
>> This is adding a bunch of expensive syscalls in a hot code
>> path, so for that reason alone this should be an option,
>> not the default.
>
> Absolutely, this is similar to how DFS is handled so it needs to be 
> optional, also I think having this in dosmode  as is in this patch is 
> probably overkill
>
> It seems that only in the result of SMB2_FIND_ID_BOTH_DIRECTORY_INFO 
> do we need to set FILE_ATTRIBUTE_REPARSE_POINT for entries that are 
> 'mount points' Additionally the response flags for in the SMB2 create 
> response should be set to ReparsePoint (although iirc in my 
> investigations this didn't seem to make a difference)
Windows 10 file server sets FILE_ATTRIBUTE_REPARSE_POINT for both 
SMB2_FIND_ID_BOTH_DIRECTORY_INFO and Create requests. We might be able 
to get away with just flagging FILE_ATTRIBUTE_REPARSE_POINT for the Find 
response, but the client might overwrite that when it receives an 
unflagged Create response.

There may be more efficient methods of detecting a mountpoint crossing, 
maybe with caching or additional conditions to limit the number of cases 
to run the second stat. But I think dosmode is probably the correct 
place for it, since it needs to apply to a variety of responses, and 
since it's setting a dosmode flag.
>> Secondly, what effects does returning 
>> (FILE_ATTRIBUTE_REPARSE_POINT|existing_mode)
>> have on the client ?
>
> 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
>
> c) Worse is to the customer this appears be a regression because the 
> behaviour is only seen when you switch from SMB1 to >=SMB2. With SMB1 
> the client doesn't seem to take much notice of whatever information it 
> may have about capacities or quotas but relies on the server to inform 
> when it is no longer possible to write (due to quota exceeded or disk 
> full) With SMB2 the window client takes the information it has (about 
> quotas & capacity) and it decides not to write to the disk if it 
> determines that there is not enough space to perform say a copy (e.g. 
> the server doesn't even get told to attempt the write or copy)
>
> What effect does this have on the client ? So for the tests I have 
> done (with attached patch) results in the windows client issuing 
> FS_INFO/FileFsFullSizeInformation requests for the mount point 
> directory as needed and the capactity quota settings being honoured 
> for both file systems.
>
> Note: windows client == explorer in this case (and windows 8.1 
> specifically)
>
I tested this using Windows 10 File Explorer, and compared packets for 
Windows 10 File Server and Samba.
> This problem is appearing more and more often as customers are 
> transitioning from SMB1 -> SMB2+
>
>
>> Thirdly, isn't this a problem that could be solved by a combination
>> of (a) Don't do that, and (b) Use MS-DFS redirects ?
> sure but customers don't want to change working setups and scream it 
> was working before, this is a regression blah blah balh. Also windows 
> supports this scenario with 'mount points' a special type of reparse point
Windows 10 File Server allows mountpoints and NTFS symlinks pointing to 
outside the share by flagging FILE_ATTRIBUTE_REPARSE_POINT. This gives 
the client information about what to ask for to successfully write to 
the destination, including the FsFullSizeInfo path to query.
>> I know Samba is convenient for stitching together arbitrary
>> filesystems into one convenient point for clients to mount,
>> but this kind of thing seems to me to be something that the
>> Admin should be thinking about and taking care of in advance.
>>
>> Jeremy.
>
> Noel