5 Replies Latest reply: Apr 16, 2012 9:00 AM by PWS59
PWS59 Level 1 Level 1



I have an Apple RAID card installed with the following configuration:

  • 4 x 2TB HD's
  • RAID 0+1
  • Yielding a 4TB RAID set
  • Partitioned into:
    • Partition 1: 40GB Startup
    • Partition 2: 40GB Backup Startup
    • Partition 3: The remaining available disk space into a Data drive


The idea was I would have a reserve volume I could load another system onto and it would come in handy.


The problem is that I didn't know that the startup drive was going to have to have an accounting application running on it that needed to have its data on the same volume. This data is growing rapidly and I am in need of expanding the volume. I have a backup of the whole setup.


From what I can gather from my searches, I should be able to resize these partitions but I wanted to know if anyone out there had a similar setup and had tried this. Right now there is no data on Partition 2 so my thought was to delete this partition from the RAID set and then expand Partition 1, doubling the size of my startup. This would get rid of my backup startup but I could achieve that with an external drive.


My hesitation is because I can't find any reference to doing this with a RAID 0+1 scheme (I would have preferred 1+0 but the RAID card didn't offer it...). Does anyone have any experience with this or deeper knowledge of the issue than me who can offer some advice?


Many thanks, Peter

Apple RAID Card, Mac OS X (10.6.8), Server software
  • Camelot Level 8 Level 8
    Mac OS X

    This isn't a direct answer to your question, but it might be a simpler one.


    Few applications really need data on the same physical drive, as much as they (stupidly) hard-code paths in the application as to where they expect the data to be. That's an important distinction... you might not be able to stop it from looking in, say, /data for its files, but you may be able to setup /data as a symlink to another directory (e.g. on another disk) in such a way that the application doesn't know the difference - as far as its concerned, it's still accessing the data in /data and doesn't know that it's on a separate disk.


    It's at least worth a try. It does involve getting under the hood in Terminal.app, though, and is a three step process:


    1) copy the data directory to the larger RAID partition

    2) move the existing data directory out of the way (e.g. rename it)

    3) create a symlink that binds the copy of data from step 1 to appear in the original location just vacated in step 2


    It's that third step that requires Terminal, since you should be able to copy the data and move the existing directory in the Finder.


    So, assuming that

    a) /data is the directory you want to move, and

    b) /Volumes/RAID/data is the name of the directory on large RAID partition where you copied the data to


    you can:


    sudo ln -s /Volumes/RAID/data /data

    This tells the OS to create a link at /data that really points to /Volumes/RAID/data


    If all goes well you can then relaunch your accounting application and it should just work. If it doesn't, for some reason, just delete the /data symlink and rename your original directory back.

  • Christopher Murphy Level 3 Level 3

    I agree with Camelot. I would exhaust other options first. I'd even look into using NFS exports, which will act locally even though they point to a shared folder on another disk. I'd be really irritated if someone had stuck in hardwired absolute paths to the local disk.


    I do not believe Apple is using a device mapper for software RAID like on Linux. A device mapper behaves like a block device, so it gets partitioned, accepts volume groups (like Core Storage but more advanced), and file systems can be resized.


    Do a 'diskutil list' and 'df' and post those results, see if how these disks are being married together. You might post this question on the file systems list serve, a couple of Apple engineers monitor that list and might have a suggestion if it's possible.


    If the mounted partitions can be merged, the command to use is 'diskutil mergePartitions' you can 'man diskutil' to find the section that discusses it. The first partition data is preserved so long as it is JHFS+/X and all data on the 2nd, 3rd, 4th, etc. partitions are destroyed. So definitely make sure you get the order correct and that you have a backup before you start.



  • Christopher Murphy Level 3 Level 3

    The results of 'mount' might also be useful.

  • Christopher Murphy Level 3 Level 3

    Duh. RAID Card. Helps to read.


    So from the OS's point of view, it's a single block device, on which there's a partition map and three file systems. So assuming this is a GPT disk, s1 will be EFI System, s2 is your partition 1, s3 is your partition 2, and s3 is your partition 3. To merge your partition 1 and 2:


    diskutil mergepartitions /dev/diskXs2 /dev/diskXs3


    Where X is the device number.


    For software RAID, it just isn't the same. The choice is a single virtual device backed by RAID0+1, which cannot itself be partitioned and formatted. Or to partition first, and then produce the RAID sets, which cannot be resized. This is vastly easier to do with linux dev mapper and logical volume management. But with a RAID card, all of the RAID stuff is abstracted from the OS, so it appears those four disks are a single device.

  • PWS59 Level 1 Level 1

    Thanks for the help guys!


    I actually found a bunch of largish files that, after deleting, have freed up some space for the time being. I may have to do this down the road though.