Resizing Partition with Apple Raid Card

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.

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.

https://lists.apple.com/mailman/listinfo/filesystem-dev

The results of 'mount' might also be useful.

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.