7

Hopefully this question is objective and appropriate for ServerFault...

I've read in numerous places that DFS-Replication is not supported on CSVs but have yet to come across any information which explains why it is not supported and what sort of problems we can expect to face if we deploy our DFS file servers on our storage cluster.

We're running Windows Server 2012 R2.

Any information about this would be greatly appreciated. Thanks in advance.

7
  • 1
    I believe it's because of the way that NTFS is designed as a monogamous filesystem. I can't find an official resource that says "this is why," but I think the article here on the introduction of CSVs explains the inner design considerations of NTFS and CSVs well enough to indicate that DFSR just doesn't play well with the way CSVs are designed. No small stretch, considering how fragile and touchy DFSR is, even under ideal conditions. Mar 18, 2015 at 16:58
  • Thanks for the response. I suppose providing a definitive to any "why" type question is not going to be easy. If nobody comes along with a better answer in the next couple days you should consider offering this as a potential answer to be accepted. Mar 18, 2015 at 17:21
  • I'm still somewhat hopeful I can find an official resource that references something DFSR requires, which isn't possible in a CSV, but yeah, if no one can do any better, I'll expand on that comment as an answer in a few days. Mar 18, 2015 at 17:34
  • I've read in numerous places that DFS-Replication is not supported on CSVs - Can you provide links to those sources?
    – joeqwerty
    Mar 18, 2015 at 17:49
  • 1
    When I posed the question I was thinking this meant that I couldn't run a DFS server on a VHDX running on Hyper-V. I've since learned that DFS-R on a VHDX which resides on a CSV is supported and not the same scenario. However, I've left the question up here for posterity sake and intellectual curiosity. Mar 19, 2015 at 11:21

1 Answer 1

5

According to this article a CSV is actually a CsvFs layer that hides and controls access to the underlying NTFS. It provides synchronizing services that help multiple CSV aware actors write to the filesystem without conflict.

Meanwhile, DFS-R is tied to NTFS because it works with low-level structures directly to catch and respond to creation and change events.

DFS is cluster aware because it can use an old-style lun that fails from the active node to the failover node but the whole volume has to fail at once so the DFS database and the filesystem move together. It doesn't support CSV because it doesn't support CsvFs, it wants raw access to vanilla NTFS so it can peek beneath the covers. Covers that CSV layers on top of to do exactly what DFS-R can't stand, someone else writing to the volume without notice.

I suppose they could write it for CsvFs someday but why add that complexity when it gains you nothing but heartache at the DFS-R level? If the CsvFs wound up hosted on a different node than DFS it would constantly be asking that other node to examine the low-level structures and pass all that back and would just be reacting late to every event.

I'm no expert on this low-level stuff but they seem to be pretty incompatible forms of FS magic to me!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .