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

[Noel Power]

Hi All,

So coincidently I also have been looking at this recently due to a 
couple of our customers coming across this problem, unfortunately I have 
been tied up a bit with the python3 stuff :-) I meant to post about it 
but of course things have got in the way.
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:
>> This patch addresses the problem reported in Bug 13122
>> <https://bugzilla.samba.org/show_bug.cgi?id=13122>, which describes write
>> problems when a file share contains a mountpoint or a wide link that points
>> to another volume.
>>
>> Currently, the smbd response always returns 'free units' for the volume
>> containing the root of the share. If the root volume is full and the write
>> destination is on a different volume, the client refuses to write because
>> the FsFullSizeInfo states that the disk is full.
>>
>> If the root volume has sufficient space and the write destination does not,
>> the write will proceed and truncate.
>>
>> 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)

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

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
> 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.
>
>
so, like I said I was also looking into this (didn't know about the 
associated https://bugzilla.samba.org/show_bug.cgi?id=13122) which 
mentions some problems also with Mac.

I think it would be useful to support this as a optional share setting 
(like I was already doing) does this make it more palatable Jeremy ? I 
was intending trying to do some more testing around this anyway (I only 
tested one windows client version) and possibly also extending smbclient 
allinfo to take into account reparse_point(s) (currently only symlinks 
are handled)


Noel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: wip-reparse-point-support.diff
Type: text/x-patch
Size: 8208 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20181204/7d8e4899/wip-reparse-point-support.bin>