Exchange database dismounted due to NTFS file extent limit reached – unexpected outage

Question

Hi everyone,We experienced a serious outage on our Exchange 2016 server recently, and I wanted to share what we found during the root cause analysis – in case it helps someone else avoid the same scenario.Summary:After digging deep, we discovered that the issue was caused by the NTFS file system hitting its internal file extent limit on the .edb file. Once this threshold was reached, the database could no longer grow, and the system dismounted the database unexpectedly. No prior warning, just service interruption.Details:The .edb was around 1.2 TB in size.&nbsp; &nbsp; &nbsp;This isn’t a limit on database size itself — it’s about how fragmented the file is on disk.&nbsp; &nbsp; &nbsp;Once NTFS couldn’t track any more extents, the database stopped working.&nbsp; &nbsp; &nbsp;Microsoft doesn’t publish a clear fix for this; only scattered references to similar behavior in past cases.What we did:&nbsp; &nbsp; &nbsp;Created a fresh, clean database.&nbsp; &nbsp; &nbsp;Manually moved user mailboxes into the new DB.&nbsp; &nbsp; &nbsp;The old database couldn't be mounted anymore, so we brought the system live without historical mail – just to maintain continuity.&nbsp; &nbsp; &nbsp;We're now working on extracting data from the unmounted .edb using third-party tools.Looking for thoughts:&nbsp; &nbsp; &nbsp;Has anyone else hit the NTFS extent wall with Exchange?&nbsp; &nbsp; &nbsp;How do you monitor extent growth proactively?&nbsp; &nbsp; &nbsp;Did switching to ReFS solve this for you long-term?Open to any input or similar experiences – appreciate it in advance.Thanks!

visualblind · Answer

What version of Windows Server and what version of Windows Server was the NTFS filesystem created with if it has been migrated from a previous machine?
What NTFS cluster size are you using? It's recommended to use a cluster size of 64K for Exchange databases and t-logs. Is this direct attached storage or does the datastore reside on a SAN/NAS?

There has been very little technology changes in the way of managing Exchange databases all the way back to the Exchange 5.5 days. The method back then, and the method to this very day is still to scale mailbox servers horizontally and balance the mailboxes among them in order to decrease individual database file sizes (and therefore decreasing the number of extents which the file is comprised of).

From what I understand, you can either continue using NTFS and fight the extent limit battle with enabling large file record segments and ensuring correct cluster size, or use ReFS like you mentioned.

You can do this with a single command however it requires you to format the volume:

Command Prompt:

format <DriveLetter>: /FS:NTFS /A:64K /L

/A:64K Sets the allocation unit (cluster) size to 64 kilobytes
/L Enables support for large file record segments (FRS)

PowerShell:

Format-Volume -DriveLetter <DriveLetter> -FileSystem NTFS -AllocationUnitSize 64KB -UseLargeFRS

ReFS is actually the "Exchange Server 2019 Preferred Architecture":
https://learn.microsoft.com/en-us/exchange/plan-and-deploy/deployment-ref/preferred-architecture

So, in conclusion if your goal is to utilize existing storage hardware without Microsoft causing you to invest more capital than you already have, go with ReFS. It has all-around better large file storing capability and offers better data integrity compared to NTFS.

visualblind · Answer