7

I have a couple of raid enclosures, with a total of about 21 TB usable (RAID5) in a W2K8 environment. I would like just a single virtual volume spanning the physical devices, but it is my understanding that the NTFS volume size limit is 16 TB. Is this a hard constraint or a MSFT recommendation? What is my exposure if I go ahead and roll the bigass 21 TB volume? Thanks!

5 Answers5

6

In Windows 2003, 232-1 clusters. With 64k clusters = 256TB

With full 264-1 sizing, 256 TB * 256 TB

21 TB is a rounding error, quite frankly

Did you check your facts before posting?

Jeff Atwood
  • 13,104
  • 20
  • 75
  • 92
gbn
  • 6,079
  • 1
  • 18
  • 21
  • What does "full 2^64-1 sizing mean? – jrtipton Sep 03 '10 at 21:11
  • @jrtipton: it's 2 x 2^32-1 – gbn Sep 04 '10 at 05:48
  • 1
    @jrtipton NTFS itself is designed to support volumes as big as 2^64 - 1 clusters of up to 64kB each. That is, 1,099,511,627,776 TB (over one trillion Terabytes!). However, the NTFS support in Windows (since Windows XP) only supports 2^32 - 1 clusters of up to 64kB each. That is, 256 TB. – thomasrutter Apr 05 '13 at 04:31
3

Aside from technical limitations, handling such a huge volume would be quite impractical.

Just think about what would happen if you ever had to CHKDSK it.

Massimo
  • 70,200
  • 57
  • 200
  • 323
  • 1
    We have several hundred servers with >16TB NTFS disks, we've never ran into a single FS-related problem with them in nearly 4 years of operation. That said I have to admit I've never once chkdsk'ed one :) – Chopper3 Jan 26 '10 at 20:31
  • 1
    This size is pretty common outside of the Windows world and while journaling does often improve the situation it is not really of major concern. – Scott Alan Miller Jan 26 '10 at 21:29
  • 3
    I sat thru a 12+ hour CHKDSK of a nearly full 6TB NTFS volume that was "corrupted" when an EqualLogic SAN "burped". It was painful, and made me question the utility of using volumes that big versus having multiple filesystems joined together in a single logical namespace. – Evan Anderson Jan 27 '10 at 02:48
  • @Massimo that's what people said about 20GB drives once. And they would have said it about 500MB drives once, too. But I am from the future, and I have two 3TB drives, and *yes* it's impractical to copy 3TB of data but how else are you gonna store 3TB of data? – thomasrutter Apr 05 '13 at 04:35
  • CHKDSK is one of the problems that REFS makes go away. – Techrocket9 Oct 15 '15 at 18:14
2

I just threw a 22TB LUN at one of my spare W2K3 servers, created it as GPT disk and chose 64K clusters - formatted it no problem at all, I then filled it up and deleted the content - no problems :)

Chopper3
  • 101,299
  • 9
  • 108
  • 239
  • What did you fill it up with? If you used "few" very large files (which is likely), I think things would behave quite differently when using a standard workload of smaller ones. – Massimo Jan 26 '10 at 20:30
  • it was a bunch of video content packages; each is made up of between 2 and 5 2GB files and about 12-20 pretty small files of 2KB to 128KB, each set in it's own directory - nothing inbetween at all though. – Chopper3 Jan 26 '10 at 20:34
2

Just to clarify, the maximum file size is 16 exabytes architecturally and 16 terabytes in implementation. The maximum volume size is 256 terabytes.

Basic volumes are limited to 2 TB. Even if you create multiple volumes on a single logical unit, the combined size of all those volumes cannot exceed 2 TB. If you want to use volumes larger than 2 TB, you must use dynamic spanned, striped, or RAID-5 volumes.

Dynamic disks allow you to create spanned, striped (RAID-0), and RAID-5 volumes that exceed the 2-TB size limit of basic volumes. Simple and mirrored volumes cannot exceed 2 TB.

For more information:

http://technet.microsoft.com/en-us/library/cc781134(WS.10).aspx
http://technet.microsoft.com/en-us/library/cc773268(WS.10).aspx

Jeff Atwood
  • 13,104
  • 20
  • 75
  • 92
MHGL
  • 380
  • 1
  • 8
  • The 16TB thing is simply not the case sorry. – Chopper3 Jan 26 '10 at 20:36
  • see my other responses and comments in this thread please – Chopper3 Jan 26 '10 at 20:43
  • Both HP and MS support our >16TB systems, there's no support considerations whatsoever. In fact we have on-site MS dedicated support engineers who do, among many things, the performance tuning of these boxes. I don't see where the confusion comes from, the documents Jeff linked to are 6+ years old and don't cover the FS implications of GPT. – Chopper3 Jan 26 '10 at 20:53
  • 1
    My confusion came from a lack of being able to find documentation. I was able to locate this article: http://www.microsoft.com/whdc/device/storage/LUN_SP1.mspx#EEB To sum it up: The maximum NTFS file system size that can be realized on Windows is 256 TB. Disk devices with more than 2 TB of disk space must be converted to GPT format for all of the disk space to be usable. If the device uses MBR format, the disk space beyond 2 TB will be unusable. – MHGL Jan 26 '10 at 21:01
  • Yep, I know, that's what user 'gbn' answered with first. – Chopper3 Jan 26 '10 at 21:05
  • I still couldn't find documentation supporting a single file over 16TB though. – MHGL Jan 26 '10 at 21:10
  • Nobody is saying you can have a single file over 16TB though, we're all talking about volume size here - a single file can go to 16TB minus 64KB though - again detailed in 'gbn's answer. – Chopper3 Jan 26 '10 at 21:15
  • I'm sorry, your first comment on my post confused me. The only 16TB limit I referenced was for maximum file size. – MHGL Jan 26 '10 at 21:19
1

Microsoft said in 2005 that the real limit for a spanned NTFS filesystem was 64TB on their "Storage Fact and Fiction" page.

Scott Alan Miller
  • 497
  • 4
  • 7
  • According to that document that's only for software R0 dynamic volumes though, it's 62TB for software R5 dynamic volumes and 256TB for GPT volumes. – Chopper3 Jan 26 '10 at 21:22
  • That is if software RAID is used. It doesn't apply to enterprise scenarios. If you are using hardware RAID you will have the full 64TB with any underlying RAID system and 256TB with any GPT based RAID system. – Scott Alan Miller Jan 26 '10 at 22:03