Chris Murphy
Forum Replies Created
-
Ok so maybe stop being coy and tell us what the containing directory name and hidden filenames are?
-
Go to OmniGroup and grab the free Omni Disk Sweeper.
https://www.omnigroup.com/moreIt scans volumes, and sorts directories by size. If the problem is still occurring you could screen shot the app window after it’s done scanning, then rescan and compare the recent scan to the screen shot to see which directory is growing.
It does find hidden directories that start with . and lists them as well.
-
It’s really straightforward. You have a runaway process eating up gobs of RAM, and now it’s swapping to disk and the swapfile is getting huge. You can find such a process in Activity Monitor. It will be using lots of memory and probably a lot of CPU. Make sure you sort for All Processes not just user ones.
You have a runaway process producing a lot of errors, that the system logging daemon is recording to disk, making the system.log file huge. You can find evidence of this with the following terminal command:
du -h /var/log/system*That will list the file size of all of the system logs.
du -h /var/log/
That will list the file sizes of all logs in the /var/log folder, maybe it’s really obscure and not the system.log that’s growing. If it is the system.log that’s growing, you need to look at it in Console to see what’s being logged that makes the log file so large so fast. And then kill that process.
Last, is the file system is unhealthy and the Finder is interpreting this as a file system that’s filling up.
In any case it’s not good because whether it really is or really isn’t filling up, it’s going to cause the OS to hang at some point and then your ability to figure out and fix the problem will be a lot more difficult.
-
It’s not possible to remove the physical device in a raid set. All three will appear as a single icon, which represents the logical device. It’s more likely this drive has died, or is physically detached. But I imagine you’ve figured this out by now.
-
It’s good advice as this also causes a good chunk of accumulated cache files to be deleted. But honestly, it’s really ill advised to allow a file system used as a boot volume to get this full in the first place, they have a tendency to become really fragile.
-
You’re using the same cable at work and at home? If not, change cables. If so, change cables anyway. You should also be able to boot from Recovery HD, and see and mount this drive with Disk Utility. If that works you could optionally do a file listing with Terminal which is slightly hidden in a drop down menu, since there isn’t a Finder in this environment. But I’d isolate the OS itself as a contributing factor.
-
I don’t have anything significant to add to what Bob said, but agree. A major reason for buying a MacPro is the ability to upgrade it. Take advantage of that. The things you’re upgrading are the major bottleneck in any system. The thing you’re not upgrading, the core system itself, makes it familiar and thus easier to expand further, support, and troubleshoot should the need arise. If you’re so busy that it’s actually the older Xeons slowing you down, then it should be no problem money wise to get a new MacPro when the time comes.
-
EricBowen writes: The biggest deciding factor to E-Sata Multiplexing bay performance is the E-Sata controller cards.
I’ll speculate that this is due to the difference in switching method used by the controller. Command based causes the controller to communicate discreetly to each drive via the multiplier, one drive at a time and no outstanding commands are permitted. FIS based enables the controller to, in a sense, communicate to all of the drives at the same time, with multiple outstanding requests per drive. Obviously FIS is a lot more complicated, but also a lot more efficient.
What I’m not sure of about the G-Speed Q is how this relates to its internal raid controller, since I don’t think it’s up to the computer SATA controller to talk to the drives. The G-Speed Q controller presents a logical drive to the computer SATA controller which should just spit out a stream of data to the G-Speed Q. And then it’s up to the G-Speed Q controller to divvy that up into data and parity chunks, and deliver them to the proper drives. So I’m a bit puzzled why the controller matters in this case.
-
This isn’t expected. Apple has been creating GPT partitioned disks for some time, and I know the layout is identical between OS 10.6 and 10.8.
There’s a rather obscure way this could happen if the volume you’re formatting is actually a CoreStorage logical volume. SnowLeopard predates CoreStorage so it would have no way of locating or reading that volume. But as far as I know, in the GUI the only way you get CoreStorage logical volumes is if you create an encrypted volume.
Do you have any messages in Console for the time of this “not readable” message on Snow Leopard?
In Disk Utility, clicking on a partition, then clicking Erase, preserves the partition map. Clicking on the whole drive, then clicking Partition, and changing the setting from Current to any other option (e.g. 1 Partition), and then erasing will overwrite the partition map. Which method are you using when reformatting?
-
Plug in one of the problem drives, click ignore in the initialize dialog, go to terminal and type this read only command and post the result:
sudo gpt -r -vv show diskX
X is the number of the drive, if you don’t know it you can use:
diskutil listThat will list all devices and their disk number in the identifier column.