Daily TechnoTips: Disk Considerations for Large File Share Servers

While working here at Microsoft, I have noticed over the years that many administrators have been creating large single volumes for file shares. This has become more prevalent as storage space has become cheaper. With SAN attached storage, a disk can be carved to just about any size and I have seen single file share volumes in access of 80TB.

From an administration standpoint, having a single disk or volume that can grow over time as space is needed by the users is very simple to manage. All an administrator has to do is add more space to the end of the disk and extend the volume.

So here is a question you might want to think about. What happens if that disk or volume becomes unavailable? How long will it take to get the share back online?

Those questions are some a lot of administrators do not think about. For most, it is panic and a frantic rush to get the data to the users as quickly as possible and a call to Microsoft. If you ever had this happen to your file server, I’m sure you know the feeling when all the users are not able to access their data, especially if it is someone from upper management.

My goal with this Blog is to help minimize the effect of losing shares when a disk goes bad by using multiple drives and mount points.

Below are some of the reasons using Mount Points for large file shares as an alternative to having one large, single volume is a better option.

If file system corruption occurs, it may take days to run CHKDSK against a very large volume.
Restoring data from backup can take hours or days.
If the disk goes down or becomes unavailable, all users that use that share will not have access to their files.

When using mount points pointing to smaller disks, you are reducing the chance of all your users losing access to their shares in case of a disk failure. You also get a performance increase since data requests are spread out across multiple disks.

You can design this to where one disk would hold the mount points and the root share. The other disks will be used to hold folders that are split up between the users or groups of users.

In my example below, I use Disk U: as the mount point storage disk with a folder called “Users” as my root share. Then I create folders A-Z to be the mount points. The U: Disk size is 100MB

Disk U:\Users\A-D\

Disk U:\Users\I-L\

Disk U:\Users\M-O\

Disk U:\Users\P-T\

Disk U:\Users\U-Z\

Each folder (Mount point) would in turn be mounted to a disk.

A-D – Disk1

E-H – Disk2

I-L – Disk3

M-O – Disk4

P-T – Disk5

U-Z – Disk6

In this example, if one disk goes down, you only lose 1/6th of your data or user access, not 100% as with a single large volume. The other advantage of this type of configuration is running CHKDSK or restoring data from backup will not take as long if needed.

Increasing space on the mount point disks will also be easier. As users add files to the share, you can see what drives fill up faster and only add storage to the heavily used shares. You can also rearrange or add mount point folders to better accommodate usage so data is distributed more evenly across all disks and the disks size does not grow too large.

If you are configuring drives and shares for a new file server, then setting up mount points should not be much more configuration than normal. If you are going to implement this to an existing file server, it is much more involved as you would need a redesign of your currently used LUNs and would be much more time consuming.

Below are the steps I took to make the file share and mount points on my server.

1. Create the folder structure on the mount point drive.