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

[Daniel Fussell]

Like a goof, I accidentally responded directly to Jeremy instead of the list.

I'm resubmitting my intended post here for posterity.


On 12/3/18 1:22 PM, Jeremy Allison via samba-technical wrote:

> On Mon, Dec 03, 2018 at 01:11:38PM -0700, James Ashdown via samba-technical wrote:
> 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.

I think that would be a decent alternative, if the mountpoint crossing
detection can't be optimized.

Unless I'm overlooking syscalls, this adds one stat per dos_mode call. 
Opening a directory would probably be the worst-case cost, where every
entry would need a stat.  Would it be reasonable to add each entry
dos_mode handles to the stat_cache?  Would that be enough to reduce the
stat cost without affecting other well-behaved cached entries?

Now that I think about it, Samba really slows down on large directories
too.  I'm guessing this is due to the same high stat cost for resolving
each directory entry, and being constantly rescheduled behind some other
process.  Or would it be from increasing hash collisions in stat_cache?

> Secondly, what effects does returning (FILE_ATTRIBUTE_REPARSE_POINT|existing_mode)
> have on the client ?

For Windows Explorer (haven't tested others yet), the reparse point flag
indicates the previously-queried dfree information (and maybe more) is
not valid for a returned path entry.  The client subsequently queries
the dfree for the affected path using query_info (as I recall).  I
believe the same thing happens when handling dfs paths.

This is, of course, based on wireshark dumps of windows client/server
behavior when using volume mountpoints on the server side.

This same flag might also be used in vfs modules that override dfree to
disable freespace checks due to directory quotas, if any such affected
developers are so interested.

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

(a) Not necessarily, it can be hard to know how data will grow and how
much software now depends on a specific path.

(b) This reparse point flag appears to trigger similar processing to
DFS, though IIRC the DFS client then issues an open DFS link op for the
affected path, similar to SMB2 SYMLINK processing.  It's been a while
since I looked at DFS processing though, so I could be wrong.

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

In our case, the filesystems are stitched lower than that, so as to have
exactly the same paths for both Samba and NFS clients, as well as other
ancillary benefits.  But I recognize we are a heavily customized shop,
and most people probably don't care.  There probably is more ways to
skin this cat, but this works very well for us.

As for more run-of-the-mill shops, they may have simply underestimated
how large their video repo would get, and now need to fork it out to a
larger device without changing the established file hierarchy and
without the complexity of DFS. 

It really doesn't matter what prompted the use of nested mount points;
that's for the admin/user to decide.  But it does seem reasonable to
expect if a Samba path has crossed a volume mount point, the client
should be (or at least have the option to be) informed.

Daniel