Author Topic: SATA in QS2002  (Read 7151 times)

Offline baraktorvan

  • Active Member
  • *
  • Posts: 11
  • new to the forums
SATA in QS2002
« on: August 24, 2015, 04:18:34 PM »
I have two SATA 1TB hard drives that will be attached to a PCI controller card on a Quicksilver 2002 800Mhz.

So if i want to install OS 9.2.2 on it., can I leave it at the 1 TB size or will I have to partition it into smaller drives OS 9 can see?

I ask as I have a 130GB SATA drive which OS9 is inhabiting, but it is running out of space. I want to replace it with one of the 1TB drives. The other one I want as a storage drive only.

supernova777

  • Guest
Re: SATA in QS2002
« Reply #1 on: August 24, 2015, 08:11:38 PM »
u have to make the bootable first partition for os9 less then ... help me out guys.. i forget exactly.. i think the limit is.. 128gb?  its larger then that. i think on a qs2002 u can go to 250gb
to be safe i would just make a 128gb partition and then the rest of the drive on the 2nd partition, unless u want to boot X too.. in which case id make 2 x 128gb partitions + the remainder

but the pci sata controllers rock on g4's (y) congrats

Offline DieHard

  • Global Moderator
  • Platinum Member
  • *****
  • Posts: 2374
Re: SATA in QS2002
« Reply #2 on: August 24, 2015, 11:02:14 PM »
We have many topics on the subject of using Large Hard drives under OS 9... and many of the Pros and Cons are discussed already...

Please search and read them as they go into more detail...

A quick answer would be that if your QS is going to be an "OS 9 Only" G4 then multiple partitions of about 190 GB would be a good game plan (per each 1 TB Drive) since you can perform volume repairs, defrag volumes, and also Boot off the different volumes to perform these tasks in a pure "OS 9 Only" environment.  You can also specify whether you want a volume formatted as "Extended" or not (pros and cons also discussed in some other topics)

If you plan to use a large drive as "Storage Only" volume (as you mentioned), then OS 9 will see the 1 TB drive as a single volume, but if the volume gets damaged/corrupted in any way (like a freeze or power failure while writing data), then hopes of fixing the volume (under OS9) may be lost.

In a dual boot environment (with 9 and X), data repairs/drive maintenance will be less of an issue, but please be aware that OS X may write volume info. to an OS 9 shared volume that may generate both file names that are unreadable in 9 and/or volume header errors that OS 9 disk repair utilities cannot fix, that is why some of us (like myself and Mactron), prefer NOT to mix X and 9 on the same G4, they play much nicer on separate units :)

Offline mrhappy

  • Platinum Member
  • *****
  • Posts: 1152
  • new to the forums
Re: SATA in QS2002
« Reply #3 on: August 25, 2015, 07:05:03 AM »
please be aware that OS X may write volume info. to an OS 9 shared volume that may generate both file names that are unreadable in 9 and/or volume header errors that OS 9 disk repair utilities cannot fix

I'm a big believer here as I've had that happen numerous times using portable drives... I would get all kinds of 'B-tree' errors... at first they could be repaired but eventually they'd make the drive unuseable!

Offline DieHard

  • Global Moderator
  • Platinum Member
  • *****
  • Posts: 2374
Re: SATA in QS2002
« Reply #4 on: August 25, 2015, 07:49:46 AM »
Yes... the famous "
Quote
Invalid Btree Header, 0, 0
" is one negative side effect of a Dual boot system... even if 9 and X are on Totally separate volumes/drives, this error can occur from accessing data on the 9 volume from OS X. After many years of making dual boot G4s (in every possible configuration) for myself and clients, it became apparent that OS X quite simply writes information to the Volume Header that OS 9 cannot recognize... most of the time this "extra info" can exist and the Disk first Aid in OS 9 will companion, but still work fine... it is when additional errors happen on an OS 9 volume (that would normally be repairable in OS 9) that this extra data stops the DFA "normal repairs" from working.

As a side note... I have NEVER seen the "Invalid Btree Header, 0, 0" error on a G3/G4 that ONLY has OS 9 or a G3/G4 that only has OS X... that is why I personally advice to have 2 G4s and not mix OS X & OS 9 together on the same unit... Network transferring of files will NOT produce any issues/errors, only direct assess on an OS 9 Volume from OS X.

Lastly, if you never got any errors, and run both side by side, then peace be with you.... this is only a suggestion, not a debate :)
« Last Edit: August 25, 2015, 08:10:23 AM by DieHard »

Offline mrhappy

  • Platinum Member
  • *****
  • Posts: 1152
  • new to the forums
Re: SATA in QS2002
« Reply #5 on: August 25, 2015, 08:04:01 AM »
even if 9 and X are on Totally separate volumes/drives, this error can occur from accessing data on the 9 volume from OS X

That's EXACTLY what was happening!!

Offline IIO

  • Platinum Member
  • *****
  • Posts: 4444
  • just a number
Re: SATA in QS2002
« Reply #6 on: August 28, 2015, 08:52:00 AM »
the volume limit to boot OS9 is 192 gb, but if you have bad luck some cards wont support it anyway...
insert arbitrary signature here

supernova777

  • Guest
Re: SATA in QS2002
« Reply #7 on: August 28, 2015, 08:22:35 PM »
the 192 number is a number diehard found out about errors re: using norton defrag
u should keep boot drive partitions under 120gb to be safe

Offline Protools5LEGuy

  • Global Moderator
  • Platinum Member
  • *****
  • Posts: 2761
Re: SATA in QS2002
« Reply #8 on: August 28, 2015, 08:51:55 PM »
Revisiting http://macos9lives.com/smforum/index.php?topic=1941.0

Ok, finally got around to revisiting this. Spent a few hours repartitioning and testing. First thing's first: all setup was as follows:

Drive Setup 2.1 under OS 9.2.2
HFS+ partitions

While the suggestion was made to use HFS partitions instead, I did try that at one point, but ran into a (repeated) freeze when copying files, so I didn't bother any more with it.

At any rate, to recap, I had the drive partitioned into 100 GB and 970 GB volumes. All volumes worked fine for most programs, but Pro Tools (LE 5.0.1 and 5.1.1) wasn't working correctly on the 970 GB volumes:

So, anyone still running ProTools 5? I ran into a bit of a snag.

Everything is now booting fine, and I'm not having any issues accessing or opening files on any partition. However, while PT 5 is opening up sessions on the 100 GB partition just fine, if you copy them to one of the 970 GB partitions it isn't properly reading the files. Sometimes playback results in noise, while other times it results in a different file being played.

I can open the files in other editors, and they are fine. But PT 5 is having problems accessing them.

My question is, before I go too far trying to troubleshoot this, are there any known partition and/or disk size limits for PT 5? I'm hoping I can just repartition and have more smaller partitions, but I'm wondering if anyone knows offhand.

And some previous comments/suggestions:

Do you know that a 2 TB drive will work with Pro Tools? How about a 1 TB drive? Do you have experience with this? How about partition size? How large of a partition can Pro Tools handle successfully?

From experience I can add that a 400gb drive partitioned with one partition that takes up the whole drive works just fine in Pro Tools 5.1.3cs11. No issues to report what so ever. The only problem was defragmentation, but that got solved anyway.

The only reason I put in the 200gb drive when the 400gb failed was because it was what I had laying around.
lukpac: excuse me when i didnt read the whole thread, but weren´t you mentioning you use 970 gb partitions? this could be the second alternative why things dont work. would be interesting to see if the protools problem goes away when you partition 4x500 on that 4000 disk.

What I ended up doing was partitioning the drive, copying a session to a volume, and testing. With 5 volumes (419,430 MB volume size), Pro Tools wasn't working correctly, but with 6 (349,525 MB volume size), Pro Tools worked fine. From there I kept playing around with the size of the last partition (which, due to a bug in Drive Setup, would resize partitions 1-5 to 32 MB) until I found where the cutoff point was. And that point seems to be 418,815 MB. With a volume that size, Pro Tools seemed to run without problems. However, with a volume size of 418,816 MB, Pro Tools was playing back noise/incorrect audio/etc.

I also played around a little bit with volumes of different sizes. While there was some variability, it would appear that any partitions *after* a volume larger than 418,815 MB are likely to not work correctly. That said, I didn't play around with this too much; it seems much more prudent to make sure all of your volumes are below that size anyway.

At any rate, right now I've got the disk setup with 1 150 GB partition, 2 341 GB partitions, and 3 405 GB partitions. The reason the last 5 partitions aren't all the same size is Drive Setup has a bug where trying to make partitions 1-3 larger causes the UI to blow up, but doing the same for 4-6 is fine. So I made 1 smaller, left 2 and 3 at their default size, and expanded 4-6. I'm going to run a few things through the paces before I consider this 100% resolved, but so far so good: both 9.2.2 and 10.3.9 are booting from the 150 GB partition, and Pro Tools has been working fine with everything I've thrown at it from any partition.

Also worth noting that the maximum size you can allocate across all partitions is 2,097,152 MB.

Right now I don't have another large free drive to experiment with, but it would be interesting to see if anyone else could see if they are seeing the same thing with the 418,815 MB limit. My guess is that would see be an issue even with an old IDE drive, but again, I haven't been able to test that, yet anyway. It's at least something to work from though.
Looking for MacOS 9.2.4

supernova777

  • Guest
Re: SATA in QS2002
« Reply #9 on: August 28, 2015, 10:45:50 PM »
ptleguy: hes not using protools ;)
but yes - perhaps we should have a post documenting all of these "limits" to obey with a brief explanation + link to a more detailed reason