[Chris Gordon]

The following will dump the output to a csv file that can easily be pulled into excel. Specifically it’s dumping the following fields:
file owner, file size, date, filename (with full path)

find . -type f -name "*" -exec ls -al {} \; | awk ' {print $3", "$5", "$6, $7, $8", "$9 }' > file.csv

So what is this really doing? I’m calling the “find” command to list all of the files in the current directory and lower then handing that to ls to print out the details on the file. This is then piped to awk to print out the specific fields I care about. Finally the output of awk is directed to a file named file.csv.

One of the great(est) powers of OS X is its UNIX underpinnings. It is very common in UNIX to take a number of different commands and string them together like this giving you a lot of power very quickly and easily. Learning the command line and more about UNIX can be a bit daunting, but once you do, you can unlock a whole new world of power and flexibility.

[Chris Gordon]

Yes, you destroy the RAID5 set, reconfigure the disks as a RAID10 and reformat the volumes as necessary. Of course you’ve backed up any data you have on those disks so you can restore it all later.

Sorry, but that is very much a destructive change. How RAID5 and RAID10 work are very different in what data is where.

[Chris Gordon]

When you mount a local disk, OS X is speaking NTFS to the disk using an NTFS driver. The OS X driver only supports reading NTFS. Look for NTFS-3G for Mac if you really need read/write to a local disk.

When attaching over the network, OS X is using the CIFS/SMB protocol which is a network protocol for access disks (and some other resources) just like AFP or NFS. The fact that the actual disk format is NTFS is irrelevant in this case. It is the job of the SMB server to handle accessing the actual disk file system. Windows, obviously, has an SMB server built in. Pretty much everyone else (at least any UNIX-like OS) uses Samba for SMB. This includes Mac OS X, Linux, FreeBSD, OpenBSD, NetBSD, Solaris, etc, etc ,etc. I have Samba running on FreeBSD and Linux servers with the underlying disks formatted with UFS2 and ext3 respectively. My Mac has no need to know those protocols.

As you indicated, this is similar to FTP or HTTP. The server handles the access to the actual disk and communicates with the client over a specific protocol.

Hope that helps.

[Chris Gordon]

I have a WD Black (WDC WD1001FALS-00E8B0) in one of my internal bays and it works great — get about 100 MB/sec with a single thread/queue/process writing to the disk. Apple shipped a WD Blue (WDC WD3200AAJS-41VWA1) as the system disk (2008 Mac Pro, MacPro 3,1) and it gets about 50 MB/sec for single process writes. The Black does give you a good boost.

[Chris Gordon]

You can easily dump a listing of all of the files on a disk (or in a specific directory) with find. Something like the following will list all of the files in the current directory (and its children).

find . -type f -name "*" -exec ls -al {} \;

You could then redirect this to a file and import into Excel (seems that’s a point of the referenced software) or just sort through the text file (grep, awk and sort are your friends). Of course this is very much the “unix way” and requires comfort at the command line.

Hope that helps.

[Chris Gordon]

Bob,

Did you ever find an alternative you liked?

Over the past week or so, I’ve been doing a lot of testing with iozone (https://www.izone.org) at work. It’s available in MacPorts and works just fine on OS X. It doesn’t have a GUI and isn’t perfectly suited to modeling video editing work flows, but it will give you far more data and tests that the AJA tool does. Of course like anything storage related, you really have to understand all of the different layers and what is going on with each one.

Chris

[Chris Gordon]

Typically you pay a significant premium for the “fastest” CPU where the increase in price doesn’t match the increase in performance. The only real way to know if there is a noticeable difference in performance is to test both of them out with the identical workflow you plan to use on them. My gut says you’ll never notice the difference and you’re going to be more bottle necked at disk IO than the modest gains in CPU.

As for the 128 GB disks. Look at what you’re using now and how much space that is. Will it all fit in 128 GB with plenty of free space? Good rule of thumb is to leave at least 20% of your disk empty.

[Chris Gordon]

I don’t use bootcamp, so I don’t know where it mounts, but your script could be something as simple as:

================

#!/bin/sh
/usr/sbin/diskutil unmount /Volumes/BootCamp
exit 0

================

Put the above in a text file, save as whatever you want to call it, make it executable (chmod +x filename), then add it as a startup item.

Test if first by:
1. mounting the bootcamp volume
2. executing the script (cd to wherever you put it, then run ./filename)

Hope that helps some.

[Chris Gordon]

I’ll just point out the obvious first — you’ve backed up and made copies of anything on this array, right? Something’s having problems and that could end up with data loss.

Some things to look at or try (maybe you already have):

– Try another cable. If you’re using the same one and constantly plugging and un-plugging it, it could have died
– If you can, just reformat the entire array. Start from scratch and rebuild the RAID and then reformat it. There could be some latent problem this will fix or it may just add some more data points as to what the problem may be.
– Are you getting enough power to the array? Are both of the machines getting enough power? Insufficient power can cause all sorts of odd problems.
– Any error messages (or even interesting info) in the system logs on either/both machines? Easiest way to see is Application -> Utilities -> Console. Look at the “All Messages” when trying to mount, read, write to/from the array.

Since you have two different machines both having problems with the array, I suspect something associated with the array but you could have something wrong with both machines. Here I’d first look at memory and power. The Mac Pro should log memory parity errors in the logs (discussed above) since it has ECC memory. The MacBook doesn’t have that ability — the memory type just doesn’t do that. I can’t vouch for either of those tools specifically, but it’s often good to run several different ones to track down problems like this. Memory errors can take a while to show up, so run the tests overnight (or longer if you can) to see if something turns up.

Hope that helps some. Please post with more info if nothing immediately turns up.

[Chris Gordon]

This is all part of SMB/CIFS — a “native” part of Windows and implemented via Samba on OX X. You’re using a Workgroup setup (if you were using something else you’d know as you would have had to set it up). Some things you want to verify/check: