[Patch] dosmode: Compare block devices to detect reparse points
nopower at suse.com
Tue Dec 4 22:46:13 UTC 2018
On 04/12/2018 17:51, Jeremy Allison wrote:
> On Tue, Dec 04, 2018 at 02:48:17PM +0000, Noel Power via samba-technical wrote:
>> 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)
> My problem with setting FILE_ATTRIBUTE_REPARSE_POINT on any return
> is that smbd doesn't handle these correctly.
> We set it on MS-DFS links because we handle them the right way
> in smbd on client query.
I'll have to look into it but I don't see (like you said) any handling
of FILE_OPEN_REPARSE_POINT for the tag IO_REPARSE_TAG_DFS So.. not sure
which MS-DFS client queries you mean (but I know practically nothing
> In my SMB2-POSIX branch we set FILE_ATTRIBUTE_REPARSE_POINT on
> POSIX symlinks/fifos/block/character devices because I've added
> the code to smbd in that branch to correctly handle the pathname
> queries on names we return with this.
> But in general we simply ignore the FILE_OPEN_REPARSE_POINT
> requests in smbd. git grep for it and you'll see.
> I'm really averse to returning FILE_ATTRIBUTE_REPARSE_POINT
> on anything just to get different client behavior, when we
> don't handle FILE_OPEN_REPARSE_POINT in any way in smbd.
well we could handle FILE_OPEN_REPARSE_POINT at least for mountpoints
(only if we have a config option for it set) iirc when opening a reparse
point you just need to return the tag associated with the reparse point
(in this case IO_REPARSE_TAG_MOUNT_POINT) if and only if the file
The client could only then get/set/delete the reparse point (but support
for these is afaics optional) We probably really don't want a client to
be able to create/delete/change an existing mount point on linux, it's
possible but would we really want to do it ? For the get reparse point
operation we could return some data (but that data probably would be
useless to the client) So it's debatably how useful implementing
anything other than a stub that returns STATUS_INVALID_DEVICE_REQUEST
smbd doesn't afaics need to provide any functionality for handling
IO_REPARSE_TAG_MOUNT_POINT the os already provides this (by supporting
mountpoints) right ?
> That's the core of my objections to these things.
For the general case of reparse points I get that, but... for this
specific instance handling mount point reparse point (e.g.
IO_REPARSE_TAG_MOUNT_POINT) I don't
More information about the samba-technical