Using SATA adapter to mimic PATA/IDE drive.

[netwraith]

-

I have a source for these and was wondering if I could load up a few of the 1TB SATA drives into my 4400 and have them work???... They are LBA48 compatible, but, was just wondering if some other intrepid soul had already tried it...

[blue68f100]

To my knowledge no one has tried it. Mainly because mfg have been make the larger drives with the EIDE. The Guardian OS supports large drives, so I don't see it being a issue. It all gets down to timing with raid5 arrays and do you have enough room.

[OzDave]

I am running 2 x 1TB SATA drives in my Snap Servers 2000 using a SATA adapter. It all worked perfectly. I did have to modify the HD mount frame as the drives with the SATA adaptors sticking out don't fit normally. I ended up putting in longer cables, running them under the frame and reversing the drives, ie the drives are normally mounted with the connector at the bottom, mine are now mounted with the connector at the top. The SATA adaptor sticks out over the RAM chips which works fine.

[blue68f100]

What drive configuration are you using? Raid 1

[Phoenix32]

Remember people, in any striped RAID arrays (0, 5, 6, etc), timing is everything. While they may work, it is risky because the SATA/IDE interface adds in yet one more place to get timings a little off. For RAID 1, it should not be an issue, but in RAID 0 or the more common RAID 5 (in 4 drive units), this could easily turn into a nightmare that could strike at any time (early, or down the road when you least expect it).

[bitor]

Very interesting...keep us posted if you have any problems with this in the future. Post pics if you would like.

bitor

Originally Posted by OzDave

I am running 2 x 1TB SATA drives in my Snap Servers 2000 using a SATA adapter. It all worked perfectly. I did have to modify the HD mount frame as the drives with the SATA adaptors sticking out don't fit normally. I ended up putting in longer cables, running them under the frame and reversing the drives, ie the drives are normally mounted with the connector at the bottom, mine are now mounted with the connector at the top. The SATA adaptor sticks out over the RAM chips which works fine.

[OzDave]

I am using these devices:
http://www.newegg.com/Product/Produc...82E16812206001 Rosewill RC-203 SATA to IDE Mini Vertical Bridge.

I have JBOD configured basically because I don't use Raid 1, mirroring, (I have a second Snap for data backup), and I don't use RAID 0, striping, as Snaps can't cope with anything more than 1.1TB as there is a FileSystem restriction. I think I reported the details of this elsewhere.
I find the that the drives are heaps fast enough, the limitation seems to be in the rest of the Snap platform. Though this is just a guess see below.

I have two Snap 2000 both with the configuration of:
1x1TB WD drive (SATA + adapter)
1x750GB drive (not sure of the brand)

One of the Snaps requires Master/Slave setup, and the SATA adapters have a master/slave jumper on them.
The other Snap uses CS (though both are V2 units) and the SATA adapter did not document this configuration, just removing the jumper totally made it work.
In the M/S Snap I am using a 80 ATA cable connect the drive and in the CS Snap I am using a std 40 cable.

let me know if you need any other information.

I was researching today to see if there is anything I can tweak to get better r/w performance. I noticed in the debug menu the ethernet settings. The ethernet TBI setting seems to be related to Gigabit ethernet only from what I can find on the web. The MTU setting I am still researching. My current MTU is set to 0 bytes.

[netwraith]

Originally Posted by Phoenix32

Remember people, in any striped RAID arrays (0, 5, 6, etc), timing is everything. While they may work, it is risky because the SATA/IDE interface adds in yet one more place to get timings a little off. For RAID 1, it should not be an issue, but in RAID 0 or the more common RAID 5 (in 4 drive units), this could easily turn into a nightmare that could strike at any time (early, or down the road when you least expect it).

This probably won't be much of a problem. The reason for this is that controller is actually on the drives.. and as such, it is a synchronous process. The processor will need to wait for the controller to respond regardless. The addition of a bit of delay will slow things down a tad, but, I doubt that it will be very noticeable with the Intel NetBurst processors and GigaEther...

BTW ... thanks all for letting me know. If no one had tried it, I was going to do it when my cash crunch alleviated...

[OzDave]

Originally Posted by bitor

Post pics if you would like.

bitor

Attached is a picture - quality reduced so that I could upload it.

[Phoenix32]

Originally Posted by netwraith

This probably won't be much of a problem. The reason for this is that controller is actually on the drives.. and as such, it is a synchronous process. The processor will need to wait for the controller to respond regardless. The addition of a bit of delay will slow things down a tad, but, I doubt that it will be very noticeable with the Intel NetBurst processors and GigaEther...

I disagree, and can back it up with experience...

This "tad bit of delay" is exactly the problem. Striped RAID arrays are sensitive to timing. Anyone who has spent a great deal of time using Striped RAID arrays will tell you this.

Here is just one (of many) examples:

(coming from Western Digitial Knowledgebase Answer ID 913)

Question
Why do EIDE drives disappear from the IDE RAID array or system after a short period of error-free operation?

Answer
Problem:
WD EIDE drives are dropped from an IDE RAID array or system after several days or weeks of error-free operation.

Solution:The problem is a result of a feature that reduces idle acoustic noise in desktop drives. This feature may cause a timeout likely (though not exclusively) in an IDE RAID environment. To disable the feature, you can run a simple Western Digital utility to turn off a single bit in the drive’s run-time configuration. Disabling of this feature will NOT impact normal system operations. No firmware or hardware changes are required.


This is just one example. In this case, the acoustic setting of the drive can cause perodic slow downs of the data flow and cause the RAID to time out.

I will say it one more time. Striped RAID arrays ARE sensitive to timing. This is fact, not speculation. If the timing is off, a drive can drop out of the array as failed with no real data errors. I have seen this happen with different drives of the same size not having timing close enough and one of the drives dropping out all the time because of it.


I AM NOT SAYING these PATA to SATA adapters won't work. If the drives are the same, and the adapters are the same, the timing may very well stay within tolerances. All I AM SAYING is that these adapters do add yet another timing into the mix and MAY cause problems for your STRIPED RAID ARRAYS. BE CAUTIOUS! KEEP BACKUPS!

Many people, including myself, here on this forum like to experiment just for the experience of the experiment. No problems here with that. But not everyone likes to ride on the edge or can afford to do so. Thus where my problem comes in is when someone/anyone says, "such and such can be done" like a blanket statement without putting in the extra little information like the risks and when it won't work etc, or makes the assumption (incorrectly) that it will work in all cases.

My problem with this is for people who come to this forum for help and answers that may not know these technicalities or know any better and follow those blanket statements and then get burned by it. In this case, good EIDE/PATA drives are available up to 750 GB sizes and there is no good reason to use SATA drives with adapters other than to experiment. And, if your need goes over the 750 GB drives (and you can afford those 1GB and maybe larger drives), then you can afford a unit that was designed for them. Simple logic.

I am NOT against experimentation. I am all for it. But when you post that type of information, make sure you post the risks that go with it so those who may not know any better won't get sucked into a bad situation for them. That was my reason for posting what I did. So don't get all defensive. What I posted is FACT, and needs to be there to protect the inocent sorta speak.

[netwraith]

Originally Posted by Phoenix32

I disagree, and can back it up with experience...

This "tad bit of delay" is exactly the problem. Striped RAID arrays are sensitive to timing. Anyone who has spent a great deal of time using Striped RAID arrays will tell you this.

Well, I think we are not going to agree on this one, despite the diatribe... I am not against good data conservation practices. I simply assume that anyone who is going to try something that is not supported by the manufacturer, realizes that they need to protect themselves.

I have had a bunch of experince with arrays of all types. SAN's, FCAL, SCSI, SATA, PATA and even SASI for those who remember those. I have not seen any timing problems with ATA arrays beyond the normal ATA experience.

If we really want to get picky about this, ARRAYS should really have all spindles synchronized. But, nobody really bothers with this nowadays, and everyone assumes that they can mix and match drives as they see fit. ATA arrays work best with all drives the same brand model and firmware revision. All equal parts.

In the initial discussion I only asked for any feedback on any use of the adapters. My statement about drive timings is also from experience.. (I graduated from college in 1977 and have been in the industry ever since - ~30 years or so). But, I don't screw around with multiple vendors and such. Wait, that is not quite true. On my Clariion ARRAYS, I do mix certified drives from Seagate, Fujitsu and Hitachi... but this is all FCAL/SCSI based stuff and Clariion does the drive and firmware certifications, so, I think I can be forgiven for mixing here...

At any rate, I don't really have a problem with you disagreeing... I just don't agree with all you said...

[netwraith]

Also, BTW... the SMART logic on the newer ATA/EIDE drives gives me the most problems with ATA drives... (They often schedule self tests at odd times, and most LINUX based systems use the error data returned by the SMART logic and will fail a drive if SMART says it failed certain tests... ) I am not sure if GOS uses the SMART logic and/or has the smartctl command that most LINUX systems have. You might want to try the INFO switch and see what kind of stuff the SMART logic monitors and return to the system.... If not in a SnapServer, you might want to check it out on another LINUX box....

[Phoenix32]

Fair enough, agree to disagree... You and I have been in the field about the same amount of time. I am a hardware guy, not software, so our perspectives may come from different angles (engineering tech, R&D).

My post(s) are not really for you, but for the basic joe reading this forum who may not know these little things (like timing issues). Saving them from themselves sort of speak.

I will have to say, just for the fun of it, nothing else. You say your experience says timing is not an issue, yet in your own text you hint that timing is realavent. And for the record here, we are talking PATA here since the subject is older Snap Servers.

[netwraith]

Originally Posted by Phoenix32

I am a hardware guy, not software, so our perspectives may come from different angles (engineering tech, R&D).

I will have to say, just for the fun of it, nothing else. You say your experience says timing is not an issue, yet in your own text you hint that timing is realavent. And for the record here, we are talking PATA here since the subject is older Snap Servers.

I do both hardware and software... almost entirely UNIX based... (I don't do windows)... Many industries and environments.. (I would be bragging to list them)...

I think things here are a bit more complicated than simple logic can cover, without making a whole laundry list of truisms... Complicated systems can be chaotic.. (If you don't believe that, just look at the evolution of DNS.. worlds largest database administered by thousands of different admins and it still works... sort of...).... and often contradictory conditions can occur... just depends on whether specifications and standard are followed or ignored....

I will admit that timing is an issue, but, in a world where things are supposed to be synchronous... (remember, controller on the drive, not the adapter), there should not be any timing issues. Software needs to wait for acknowledgement from the controller. synchronized spindles did accomplish a near gurantee of simultaneous completion from all elements... (This theory assumes no bad blocks in the target areas.. as seeking to satisfy a block replacement screws everything up)... A parallel to serial (and vice versa) adapter should not, in theory, introduce any delay in signal.... In practice, it may not actually produce delay, but, may produce jitter.... (for those of you who have experience in forwarding synchronous digital circuits may remember what used to be called a tail-circuit.) Jitter means that the edge of the timed pulse may actually occur slightly before or after when it's expected. (as determined by the digital clocking) That and the fact that clocking delay is introduced by wiring length and possibly differing clock frequencies (if the adapter has it's own clock -- it really should not since it's supposed to be a slave, but, I digress even more). This is due to bulk manufacturing tolerances for components used in producing these digital adapters. I still think that any proper design should compensate for these issues, but, therein may be the rub... Proper design often is lacking in our industry... And it's more and more prevalent as time goes on... The only practice that combats this with reasonable efficacy is component matching. These days we have been reduced to matching drive brands, sizes, formatting and firmware. Since this is something that I have practiced as a matter of habit from my early days (when I actually could match resistors and other components when working on my PDP-8's rotating disk storage (DF32/RM08))... I was just laboring under the assumption that everyone knew this... My bad, I guess... Maybe I have been doing high level support for too long....

Thanks for a decent discussion... you have forced me to remember more of what I had allowed to atrophy from disuse... That seems to be what happens after you have been doing this for too long... you seem to forget about stone knives and bearskins....

[blue68f100]

I have stayed by the way side on the discussion and have a few comments. So here is my 2 cents.

Andy and I have become very good friends over the years, even though we have never personally met each other in person. What we have agreed on is that at times we will disagree. We accept that and move on.

Early years (70's) we were required to scan the surface to create a list of bad sectors. This practices is NO LONGER DONE. All rely on the SMART technology to correct this on the fly. After having Numerous issues with the OLDER Snap's multi-disk arrays (raid5) , I have started using a utility to do a full scan and build this table, prior to use. Building this table prior to use has pretty much killed a lot of timing problems. So I can safely say that the older units (2000, 2200, 4000, 4100) preform better and have fewer problems with timing.

I think the SMART tech is a very good system for single drive system and for newer hardware that support it. Unfortunately the SnapOS and related HW does not seem to support it. The Snaps seam to work with 1 SMART replacement of a bad sector. It's when multiple bad sectors are hit consecutively that throws the timing off, which in turn the snap may mark the drive as bad. Since the SnapOS is built on a heavily modified XFS on BSD (v1.1?) it is not very forgiving when you have a drive problem. The hardware controller on some snaps have a problems with EIDE drives, ultra 133. These are easier to identify due to a 40 cond IDE cable. Those with 80 cond do not seem to have the problems.

The Guardian OS is built on Red Hat Enterprise Linux and fully supports the SMART tech. Even though I ran in to issues with some 400gig Seagates that worked, without reporting errors, the performance stunk. Running my drive utility to build the table, revealed that 1 drive used up 3/4 of the reserve sectors. (I think with that many errors depending on location may eventualy come loose and crash the heads.) And another that has a very HIGH Seek error. With all of the bad sectors mapped out the drives, it now works at a higher level of performance. I can tell when the one drive is having it's seek problem in performance. I have moved this set of drives to a server that is used for archiving, and does not run 24/7. When it comes to seek problems, this is where Raid Edition Drives with a min seek time shine. As you know these drives are considerably heaver than a std drive due to more powerful servos and motors. Also if your test for performance the RE drives will out perform a std (non RE) drive when used in multiple disk arrays. There seams to be 1 drive out of the set that will have seek problems, my good luck. Now if you hand pick these drives, or have the machine to tune the drives so all match, any will work. And may have the same performance as RE drives.

Knowledge based on school of hard knocks, experience.

And as you should know by now, the Snap 4100 has a problem with larger drives and the mfg had to modify the MB's. The bad thing about this is that they only repaired the models that were shipped as large capacity. So if a user upgrade drives the problems showed up again. Snap position is that we only support what was factory shipped. The problem was related to noise on the servos impacting timing. This pretty much killed any reliability/stability in the array. So I can safely say Timing is a MAJOR PROBLEM when it comes to multi disk arrays on hardware that does not support the SMART technology.

I do think the adapters have merit, being on all drives the delay should be across the board. But why use them when you can purchase the same drive with the correct interface (IDE) at a lower price than the SATA drives + adaptes. If you are relying on a system for operation, why take the risk. Now if you are buying 1000's of SATA drives for a big corporation, I would think it's time to replace the older IDE hardware. Or make a large purchase of IDE drives to support your older system.

I would estimate that 98% of all users here on this site are home users. Some use the same equipment at home as they had at work. Mainly due to the fact the equipment was updated and the company sold the old hardware. Some are more prone to trying things out of the normal to get things working. In most all cases, this site is where users come looking for help on Snaps NAS's. More so, since Adaptec bought SnapAppliance and killed ALL FREE SUPPORT. With that said, the regulars here are more prone to support hardware as shipped. If it works for you that's great. If it fails you compounded the problem with the extra hardware.

My 2 cents are now gone so I will stop ranting.

[Phoenix32]

And this is what I love about electronics (and computer stuffs).

Both of you illistrated what I was trying and didn't do very well to say.

Most users who come to this forum are home users and most of those do not have the backgrounds you see in this thread. There is far more information and technicalities in the details than we could ever hope to post here on the forum. And even if we did, it would bore, or confuse most people reading these threads.

However, with that said, I feel it is the responsibility of those who have that farther reaching knowledge to protect those without that knowledge from some of the absolutes some try to post now and again.

i.e. "You can mix and match the drives in a Snap 4x00. I know because I did it". This is being stated as an absolute, and many people who do not know better will take it as a fact of truth, because they read it here. When the real truth is, it "might" work, and often times will, but is not recommended and also may very easily cause problems in some RAID arrays on some units. There are just too many variables and possibilities to say flat out, "it won't work" or, "it will work". You know it, I know, and I feel it is our responsibility to not let others say that one or the other is fact. See my point?

Quite often on these type forums, people have a bad habit of stating things as hard cold facts and absolutes, when the real thruth is, it worked or didn't work for them, but may have different results for others. Some things are absolute, but some are not. I feel we owe it to people to keep them sorted out. An example of a true absolute.

i.e. "The Snap 4100 is limited to 137 GB usable per drive as it was designed, without modifications to it's firmware".


Back on topic, I feel the earlier part of the thread was making it sound like using a PATA/SATA adapter was okay and an absolute (or close to it). I do not believe this is the case. It may work for one person, but not another for various reasons. I also do not think this is the best option from a dollars point of view. Thus, I was interupting and making sure people did not take it as an absolute or as the best option available. That's it. See? I just didn't want some poor sap going out and spending $ on adapters expecting it to work for them because they read it here, when it might, or might not. Just looking out for people...

[Phoenix32]

This thread does illistrate something else that people have a hard time understanding sometimes.

You get what you pay for. Why should you pay $300 (as example only) more for a Guardian Snap unit on eBay than for another one on eBay $300 cheaper (again, just an example)?

They both are say 1 TB. They are both say a 4500. So, go for the cheap one right? Maybe, maybe not.

What if one had WD RE drives in it and the other was just random drives or say basic desktop Maxtors? What if one has new drives versus the other has 3 or 4 year old drives in it? What if one has been refurbished by a tech and the other has only been glossed over by some user, some surplus seller, or some company taking it out of service? Big differences. Hell, those WD RE drives are about $90 to $95 (and up) each. That alone makes a $300 price difference seem small. This doesn't even take into account of the expensive OS.

Remember that stuff when you are buying on eBay. It makes a difference. he more expensive unit may easily be a better value. Depends....

What did this have to do with this conversation? Easy, David mentioned RE drives, and we were showing by accident in technical conversation that not everyone is as qualified as others to provide you with a rock solid unit that will serve you well for years, versus a unit that may cost you more in the long run or be problem prone. Pay attention to what you are buying...

[netwraith]

Originally Posted by netwraith

Also, BTW... the SMART logic on the newer ATA/EIDE drives gives me the most problems with ATA drives... (They often schedule self tests at odd times, and most LINUX based systems use the error data returned by the SMART logic and will fail a drive if SMART says it failed certain tests... ) I am not sure if GOS uses the SMART logic and/or has the smartctl command that most LINUX systems have. You might want to try the INFO switch and see what kind of stuff the SMART logic monitors and return to the system.... If not in a SnapServer, you might want to check it out on another LINUX box....

Follow up comment: Just for information, I logged into two different Guardian units, one 4400, and one 4500 and both had different SMART configurations. The 4400 was delivered with SMART turned off. The 4500 was delivered with SMART turned on. Both have 120GB Hitachi drives and both work without issues otherwise.

Another unit I have was inconsistent. i.e. some drives off and some drives on. That unit had Quantum Fireball drives in it. (I think they were non original drives)..

While this proves nothing at all, it may be good information for us to make a practice to check our SMART status... just for consistency reasons and perhaps better reliability. I am not going to state whether it should be on or off, since, both the 4400 and 4500 with the Hitachi drives are 100% reliable to this point. I was not having any problems with the other 4400 either, but, turned them all on just to be consistent.

On Guardian units:

The command to check the status of the SMART is:

smartctl -a /dev/hda
(Substitute with /dev/hdc , /dev/hde, /dev/hdg to check all of your internal drives).
Below are two samples using the -i form of the command... (Brief output .. still shows what's needed)
Notice how the first sample is disabled and the second is enabled (No cracks on the MAXTOR in the example... this set is pretty reliable)..

one:

# smartctl -i /dev/hda
smartctl version 5.36 [i686-pc-linux-gnu] Copyright (C) 2002-6 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF INFORMATION SECTION ===
Model Family:     IBM/Hitachi Deskstar 120GXP family
Device Model:     IC35L120AVVA07-0
Serial Number:    VNC607A6CBVTGJ
Firmware Version: VA6OA52A
User Capacity:    123,522,416,640 bytes
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   5
ATA Standard is:  ATA/ATAPI-5 T13 1321D revision 1
Local Time is:    Wed Feb 13 14:56:59 2008 EST
SMART support is: Available - device has SMART capability.
SMART support is: Disabled

SMART Disabled. Use option -s with argument 'on' to enable it.
#

two:

# smartctl -i /dev/hda
smartctl version 5.33 [i686-pc-linux-gnu] Copyright (C) 2002-4 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
=== START OF INFORMATION SECTION ===
Device Model:     Maxtor 7Y250P0
Serial Number:    Y65A9CEE
Firmware Version: YAR41BW0
User Capacity:    251,000,193,024 bytes
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   7
ATA Standard is:  ATA/ATAPI-7 T13 1532D revision 0
Local Time is:    Wed Feb 13 14:58:08 2008 EST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

#

to change the state of a drive:

To turn SMART :ON: for /dev/hda
smartctl -s on /dev/hda

To turn SMART :OFF: for /dev/hda
smartctl -s off /dev/hda

Whichever you decide, repeat the command for all drives until they are consistent.

Finally, if your unit is reliable and they are all OFF, I would not change what is working. If they are inconsistent or your unit is having reliability issues, I would turn these ON... One final note... IF your unit is having issues and you turn this on, it is possible for the unit to *COMPLETELY* fail one or more drives. So, try to get a good backup before you do...

You can check the status of your ARRAY's with the command:

cat /proc/mdstat

Here is what it could look like....

# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid5] [spare] 
read_ahead 1024 sectors
md0 : active raid5 hda4[0] hdg4[3] hde4[2] hdc4[1]      346594944 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]      
md101 : active raid1 hda5[0] hdc5[3] hde5[2] hdg5[1]      273024 blocks [4/4] [UUUU]      
md100 : active raid1 hda2[0] hdc2[3] hde2[2] hdg2[1]      546112 blocks [4/4] [UUUU]      
unused devices: <none>
#

you are looking for the :

[4/4] [UUUU] lines.... I you have ARRAYS of more or less than 4 drives, your numbers will be different, but you are still looking for all drives online. If you see something like:

<snip>
md0 : active raid5 hda4[0] hdg4[3] hde4[2] hdc4[1] (F)      
      346594944 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_]
<snip>

It means you have a failed partition and are in DEGRADED mode. You really need a backup before you do anything else... Be careful of one more thing.... It is possible for a drive to show up as *FAILED* in one array, but, not the other ... i.e. it's OK in the md100 ARRAY, but, shows dead in the md0 ARRAY... This is because the LINUX MDADM software fails partitions and not drives...

[Phoenix32]

Good information for people. Wish I had though of it...

David, maybe we need a "Guardian Unit Tips and Tricks" thread? Tips for buying, cleaning up (installs etc), and operation?

[blue68f100]

I have already started saving howto's as the problems come up.....

[netwraith]

Some more info on these.

Electrically these work fine...

Guardian Snap Servers (At least all the EIDE ones that I have come across) all use Primary IDE channels only. No secondary drives on the channel. Since there is only one drive per channel, timing does not seem to be an issue.

The issue arrives when you attempt to put these on the sled with the drives. (I did my electronics testing with an open unit and no sleds!).

I got a few of the LK-13415 adapters from NSIoutlet.com and while they work, they won't fit in the clearance space between the drive and the hot swap board without some surgery. (At least with the 4400 and 4200/4500 drive carriers).

It requires removing the jumper block from the lower long edge of the adapter board and getting new 470uF/25VDC capacitors (with longer leads) and laying them down parallel to the adapter board. I have modified one with a couple of right angle soldered stubs and it works fine, but, I think longer leads with a right angle bend would be more reliable from an electrical noise standpoint. (and that's the point of having a capacitor there anyway)... This will require a soldering iron (low power) and a few skills. If you don't have the skills, you might know someone who does. (A couple of six packs could convince the person to help... right?). A little epoxy, glueing the capacitors to the board will round out the fix.

BTW, you can find the capacitors online; ...

The IDE cable connector is a bit tight too, but, the cable itself can be reshaped with a little folding (finger pressure only) and it will fit OK. Power connector does not interfere since it's outboard of and above the level of the HotSwap board.

So the answer to the question is a qualified :: YES (I have not done extensive testing yet, and won't do it until I have the boards mounted solidly. I suspect that the SMARTCTL and HDPARM commands will work a bit differently with the SATA drives on the PATA controllers. (There seems to be differences between the drive types, since most newer controllers treat the SATA drives like SCSI drives)).

I will make a final post to this when I have all the dimensional issues conquered and my 4500 is running it's new drives on a permanent style basis. (as permanent as things get around here is a few months before I outgrow storage and need to expand).

This will likely be my last efforts at using Guardian units. Adaptec getting $xxx.xx a year for support (and the only support I need or want is :: OS UPDATES), and them insisting on getting the support fee in order to get updates (a copy of Linux (A free OS... they did not pay anything for it ... nor have I noticed any change in the proprietary modules loaded into the kernel from version to version. (Which is thier excuse to charge for the updates))) .... sticks in my craw... (I don't really care about the bundled addons and I have not noticed any change in functionality, so, it's really hard to call them upgrades) And, since OpenFiler is getting to be very robust and 1U hot swap SATA chassis are getting cheap (I got 2 1U/ P4 2ghz's/512mb RAM and 4 250GB hot swap SATA drives for $100/each the other day)... I will be running OpenFiler from now on..

(**UPDATE** After a couple of foiled attempts at capacitor procurement, I think I am going to be forced to use the right angle soldered extension and forgo the new capacitors... My suppliers has supply problems... Not a good sign for us do-it-yourself electronics experimenters .. Just a little extra epoxy around the leads to keep them stable (or a drop of RTV silicone ***)

.. and my OpenFiler units are ready and are faster than my GuardOS SnapServers ... Perhaps I will end up selling my Guardian units..

[netwraith]

--

Final update: After much fooling around with these, I am going to abandon the effort and put my time into other projects. The clearance between the boards and drives is too tight for my adapters and I am not going to go through every adapter in the business to find on that will fit without modifications. The modifications to the boards I bought (right angling the capacitors) works, but, if you are not careful, you can damage the adapter board. So, this is, in my opinion, not a great use of time. I will invest my time in upgrading the unit I will keep and spend the rest of my time on OpenFiler units. The OpenFiler software is now pretty damn good and if you couple it with a good hardware RAID, you get a (in my opinion) superior unit. My main unit is now a 24 drive SATA drive chassis w/dual Areca PCIe RAID controllers on a SuperMicro dual XEON board. A couple of GB of DDR2 ram and dual Gigabit onboards round it out. I added a fiber Gigabit and FCAL RAID adapter to service my older Clariion storage unit. I won't say what I paid for all this, but, it was not inconsequential. It's not for everyone, but, it's gonna be my path here on out...