[Patch] dosmode: Compare block devices to detect reparse points
nopower at suse.com
Tue Dec 4 14:48:17 UTC 2018
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
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
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.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 8208 bytes
Desc: not available
More information about the samba-technical