Extend non-Boot Volume (Areca RAID + Server 2008)

[Hardy]

I'm looking to non-destructively extend a non-boot volume to use hard disks added to an Areca RAID set / volume. I'm running Windows Server 2008 Enterprise.

Set-up:
Areca 1680ix-24 -- 4 disks = boot volume (C in RAID 1+0, 17 disks = data volume (D in RAID 6, 2 disks = global hot-swap drives
Chenbro Micom UEK-13601 SAS expander -- 8 disks = extra volume (E in RAID 6, with 8 more disks added to this Chenbro / Areca RAID set & related volume
C: is TrueCrypt 7.0a AES encrypted
D: is TrueCrypt 7.0a Serpent-Twofish-AES encrypted
E: is not encrypted

I believe the steps to extend a RAID volume with Windows Server 2008 are:
1) add the hard disks to the RAID controller (or SAS expander)
2) expand the controller card's RAID set capacity to include the added disks
3) grow the controller card's volume to include the added disks' capacity
4) use Server Manager's Disk Management to extend the original volume to include the newly-additional free space

It is at that last step that I'm hitting a wall. I've tried using Server Manager & diskpart, in both normal & safe modes, but get messages indicating that the volume can't be extended because the volume's file system doesn't support it (i.e., being extended). To Windows, this is a "Basic" disk, with a single "Simple" NTFS / GPT partition (of the original capacity) plus unallocated free space (of the added capacity).

Disk Management message = "The volume cannot be extended because the file system does not support it."

diskpart message = "The selected volume cannot be extended because the filesystem on the volume does not support extending."

I'd like to not lose E:'s contents, and would find it difficult to back-up all data just to format / start from scratch.

I'd consider a third-party partitioning tool, but am leery to venture too far afield without understanding why Microsoft's product can't perform the extend but a different product can.

Suggestions / thoughts?

 

[Hardy]

Bump.

Has anybody encountered this? What could be happening? How might I extend this volume?

I appreciate any help or insight.

 

[Hardy]

Update: Still Cannot Extend Volume

From what I've gathered, a volume cannot be extended if either of the following are true:
1) the volume is formatted with a non-NTFS file system
2) the disk that the volume is on is a "Basic" disk (i.e., not "Dynamic") and the unallocated free space being added is not contiguous with that volume

Similarly, a volume can be extended in either of these cases (as long as the above conditions are not true):
1) the volume is formatted with the NTFS file system
2) the volume is not formatted

Also:
1) as indicated above, if the volume is on a Basic disk, only unallocated free space that begins at the next sector offset (after the end of the volume being extended) can be added to that Basic disk's volume
2) if the volume is on a Dynamic disk, it can be extended using unallocated free space that need not be immediately after the volume, nor even on the same disk

With this in mind:
- Windows / Disk Management shows the volume to be extended as having been formatted with NTFS -- this agrees with what I believe to be the case, as I had formatted that volume (using "quick format") as NTFS
- Windows / Disk Management shows the volume's disk as "Basic" -- again, as I believe to be the case
- this volume is not able to be extended using Disk Management nor diskpart
- so, a conclusion could be drawn that the volume cannot be extended because the unallocated free space is not contiguous with (& after) the volume, even though it appears to be so
- another conclusion would be that the volume's file system is not actually -- or not seen by the "extend" function as -- NTFS

If the unallocated space is not immediately after the volume, converting the disk to Dynamic should resolve the conflict. In fact, I did convert that disk to Dynamic, but still get the same failure error message when attempting to extend the volume.

If the NTFS file system is seen by Disk Management's / diskpart's "extend" function as non-NTFS, then the error messages make sense; namely, that the volume cannot be extended because the file system does not support it.

However, in that latter case, (1) why is the file system not seen as NTFS (when it actually is, and shows so in Disk Management & the volume's properties), and (2) how can I get the "extend" function to see the volume as it really is: as NTFS?

Bottom line: at this point, I have an NTFS volume on a Dynamic disk, along with unallocated free space, but cannot extend the volume to include that free space.

I welcome your help & comments.

 

[odditory]

QFT and post a screenshot of your diskmgmt.msc window.

i'm guessing you have a cluster size issue and you probably left it at default 4k when you originally formatted (common mistake), so report what cluster size you formatted the volume to. if you don't know, run chkdsk.exe against the volume and report what it states for "X bytes in each allocation unit"

 

[Hardy]

Thanks for the reply, Odditory.

Indeed, the allocation unit was left at Default, and is 4096 bytes.

How does this affect extending a volume?

chkdsk info:

The type of the file system is NTFS.
Volume label is JPB EXTRA.

* * *

Windows has checked the file system and found no problems.

  11443959 MB total disk space.
  11441265 MB in 17588 files.
      9248 KB in 670 indexes.
         0 KB in bad sectors.
    442331 KB in use by the system.
     65536 KB occupied by the log file.
   2307216 KB available on disk.

      4096 bytes in each allocation unit.
2929653759 total allocation units on disk.
    576804 allocation units available on disk.

Disk Management screenshot:

 

[Hardy]

I think I understand -- cf. Default cluster size for NTFS, FAT, and exFAT.

Thanks for pointing me in this direction, Odditory, and I believe that cluster / allocation unit size is the issue.

Questions:

1a) can I change the volume's cluster size w/o losing the data
1b) if so, how might I be able to do it (i) safely & (ii) efficiently

2a) is it worth changing the disk back to Basic (from Dynamic)
2b) if so, how might I be able to do it (i) safely & (ii) efficiently

3) in light of the answers to the above questions, could / should I
a) create a partition out of the unallocated space, then
b) move the data from the existing volume to the new partition, then
c) extend the new partition (volume) to include the existing volume's space

Or, if I convert the disk back to Basic (from Dynamic), I could move the data back from the newly-created partition to the newly-reformatted volume, then extend that volume to the space occupied by the [temporary] partition.

Recommended approach?

 

[wkearney99]

No you cannot change the cluster size. It's set during format. Nor can you reliable change a dynamic disk back to a basic one, especially if any dynamic-only features have been used on it.

You have backups, right? Delete the volume, rebuild it and reload the backup. Might not be the news you want to hear but that's what it'll take.

 

[Hardy]

Thanks, WKearney99.

I [quick] formatted the extra space as a separate volume, using a 32k cluster size, and am now copying the data from the original to the new. Once done, I plan to delete the original volume & extend the new volume by adding the original volume's space.

Because I can't go back to Basic, being Dynamic I should be able to add space that is not immediately after the volume being extended.

Any downside to keeping the disk Dynamic?

 

[danman]

Why do you want it dynamic?

 

[wkearney99]

The upside to dynamic is you get to do more things with the partitions. Like extend them. The downside is you can't use tools other than those in Windows to edit the disk if it's using any of those features. I believe there are also size limitations with basic disks.

There's something to be said for keeping things as simple as practical. Use what's necessary.

 

[odditory]

@wkearney: Dynamic Disk mode isn't a requirement for disk resizing in diskmgmt.msc -- I leave ALL my partitions Basic, even two monster 60Tb partitions (32 x 2Tb drives Raid6) are just Basic. You can go read up on differences with Basic vs. Dynamic, I think the main diff is the software "raid" (big cough) functionality built into Windows Server requires Dynamic.

@Hardy: You can in fact resize clusters with partition tools like Acronis Disk Director, Partition Magic, etc without losing data. but its still playing with fire and I wouldn't perform it without a duplicate copy of your data. It sounds like you found your own approach in any case.

 

[Hardy]

DanMan, I'd prefer it to be Basic, but based on advice from Areca that the reason I couldn't extend the volume was because it was not Dynamic, I changed it from Basic to Dynamic (after much soul-searching & trusting the advice), knowing it'd be tough to go back to Basic. Like Odditory, I prefer to leave all Basic, if possible, but now am stuck w/ this Dynamic disk, and short of moving all data off & starting again, I'm just going to leave it Dynamic (& hope I don't experience the performance hit others have).

I did format the unallocated free space as another volume, with 32k-byte cluster size, then moved the data to it (being unsure whether I'd extend that volume or not).

I [quick] reformatted the original volume with a 32k-byte allocation unit size, and am now moving the data back to it. Although not necessary for extending Dynamic volumes, I'd prefer to have the unallocated space (into which I'm extending the volume) immediately after the volume being extended.

Once done, I'll delete the 2nd volume and exend the 1st volume to include that 2nd volume's unallocated space.

Should take a few days for each of the move data & extend volume steps, so I'll be "down" for another week -- a small price to pay if this works in the long run.

Thanks for the tips, advice, & feedback.

 

[wkearney99]

You really would have been better off moving the data to a whole other drive (or just reload backups) rather than doing that dance. Then you'd have been able to use the whole thing as a single volume with the desired cluster size. Instead you've painted yourself into future corners... Yeah, it'll work that way. And if/when things go wrong there are ways to recover, but they are simpler when not having 'extended' volumes in the mix.

 

[Hardy]

Probably true, WKearney99.

With what I had available, however, including no other connectable 12 TB of free space, this is a workable solution -- if the "Dynamic" & "extended" don't rear ugly heads (e.g., greatly reduce performance).

I'm counting on the SAS communication channels being the primary bottleneck (given RAID 6), so am not too worried about reduced access times & throughputs.

Will post results (scheduled completion in ~1 week).

 

[Hardy]

Wondering aloud . . . let's see: (1) a 16 TB drive is formatted by Windows using a default 8k-byte cluster size, but that default can be changed during formatting to a 4k-byte cluster size (I presume); now: (2) extending an 8 TB drive that was formatted (using a 4k-byte cluster size) to include an additional 8 TBs results in a 16 TB "drive", which Windows "prefers" to have 8k-byte clusters (thus the "extend" fails {wrong cluster size}) -- given these 2 conditions, I wonder if it is possible to change the cluster size permitted by the "extend" command, such that it allows a non-default / non-8k-byte cluster size . . . just wondering . . .

 

[Hardy]

Wrap-up:

It appears the issue was, in fact, with the allocation unit size [thanks, Odditory]. After reformatting with a 32k-byte cluster, the volume could be extended to beyond 16 TB, and is now functioning as expected.

Thanks for all the helpful input.