On 29 July 2015 at 18:59, Niall Douglas
On 29 Jul 2015 at 18:09, Gavin Lambert wrote:
On 29/07/2015 14:06, Niall Douglas wrote:
I appreciate you're saying the cost is worth it, but we're thinking all Boost users here, not just the small minority on Windows Server 2012 with dedup turned on.
I'm not on Server 2012, but this thread caught my attention because I remember encountering a bug that prevented all WinXP clients from accessing deduped files on CIFS shares provided by Server 2012. I think in the end this was a server-side bug related to McAfee and the different protocols used by WinXP vs. Win7, and so clients shouldn't normally be able to see whether files are deduped or not remotely, but I haven't explicitly verified that. If CIFS shares do expose files as dedup reparse points instead of concealing that then it might affect quite a lot of users.
I had understood from the OP that CIFS is exporting the reparse point tag to clients, hence the breakage.
The reason, I suspect, that CIFS is being so braindead here is that opening a deduped file is more expensive than usual and clients ought to know. Which is exactly why I am opposed to treating these things as a regular file.
On the topic of "this file will be slow to read", IMHO this is an orthogonal issue. It might be nice to be able to query some sort of "this will be hell slow to read" status so I could perhaps do something about it, But the files (slow or not) should still be treated as normal files. This problem is bigger than just reparse-point files. Reparse-point files (not symlinks/junctions) are just one type of maybe-this-will-be-slow files. Reading off the local underutilised disk is a lot faster than a local disk suffering high IO, On monday, "K:" might be a lot slower than the "M:" because the K drive is a distant server on a slow network, and the M: is a fast server on the local subnet. On tuesday, it perhaps is the opposite because I've flown into the site hosting the K:. Perhaps a network file read is slow one minute (on 3G network) and fast just one minute later (switch on WIFI). But, the current system doesn't tell me anything about that. Nor does boost treat the K: files as "special" files just because it *might* be slow. So I don't see why we should start treating (eg dedup) reparse files any different. Speed of a read is an orthogonal issue, and often not something that I can do something about. If its going to take 5 minutes to read that Word document off the disk, then that's what it takes. I can't read that file any other way. If its a problem for my software, I'll need to read it in a nonblocking way, with the ability to cancel and show progress etc. But the simple case is to block on the read, and my users are cool with that because most software works that way. cheers, Paul