[Patch] dosmode: Compare block devices to detect reparse points
james at et.byu.edu
Wed Dec 5 18:45:33 UTC 2018
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
>>> 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
>> 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
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.
More information about the samba-technical