PeterB

Thanks! That is very helpful.

Hi Shawn, Are you able to give some indication of the size of the cartons which these units came in? I'm particularly interested in the iStar (although I know that the BPN is slightly smaller than the BPU, I guess that the cartons will be much the same size). I need this information in order to estimate shipping costs in the event that I have them shipped from USofA. I have a horrible feeling that adding shipping costs will make the exercise prohibitively expensive. One supplier has already told me that, on top of the actual shipping costs, there would be freight handling charges added ($25 export fee and $20 inbound freight cost). The big unknown, especially here in Phils where demands for 'rush fees', or some such, is the norm, is the cost of getting the units through customs. The cost of the three units themselves would be $257. Can anyone here suggest a reasonably cost-effective, but reasonably secure, method of shipping three units internationally? In the end, I may have to accept the Supermicro units, because that is the only supplier with an official distribution in Philippines. Even then, I expect that the price will be almost double that in the states.

That is a little puzzling. If the specs on the SM site are to be believed, the CSE-M35T-1 does not support hard drive failure indicators, but the CSE-M35TQ does. Then I have the CSE-M35TQ's. Mine have the hard drive failure indicator in the front. Hey, if yours say M35T-1 on them, then I'm not going to disbelieve you. After all, most websites are, at best, incomplete and , at worst, downright wrong! I believe that the drive failure light is actually on the tray bezel, not on the main unit and I'm sure that he trays are common between the units.

That is a little puzzling. If the specs on the SM site are to be believed, the CSE-M35T-1 does not support hard drive failure indicators, but the CSE-M35TQ does.

The -BPL variant is the one with lockable tray. There is also a BPU-350SATA-BLACK which is the black version of the other colours, with a non-lockable aluminium handle. See here. There are pictures of both black versions. My current suspicion is that the -SATA version is the sata3 compliant replacement for the older -SA version which was only sata2. Both versions were available with either style of tray. In fact, the trays are probably exactly the same for the sata2 and sata3 versions and, I suspect, the lockable and aluminium handle trays are interchangeable - in other words, you could mix tray styles in a single backplane.

If you don't absolutely need the hdd docking station, the V5 is a better bet. The differences, as far as I'm aware: o The V5 has a large handle on top - not too useful as a handle on a file server, but it certainly stops you obstructing the top fan by laying things on top of the case! o The V5 has only one fan aperture (with fan fitted) on the top panel - slightly further forward than the active fan on the V6 o In place of the docking station, the V5 has an eSATA socket. This does not obstruct the top bay so that it should be possible to install three full 5in3 backplanes o The V5 is slightly cheaper than the V6 I believe that, in all other respects, the two cases are identical. This, to my mind, makes the V5 an ideal case for a mid-sized (15 drive) unRAID configuration. It is stylish (as long as you don't object to the handle), extremely quiet. Easy to cool. I would much rather have the full 9 bay capacity, than the docking station - If I really want/need to attach another drive temporarily, I would use an eSATA enclosure (possibly with a trayless hot-swap facility). The only caution I would give is that I suspect it's not deep enough to comfortably accommodate the largest drive backplanes (Norco and Supermicro). I plan to install iStar trayless backplanes (if I can get hold of them), otherwise I will try the Supermicro. At least there is latitude to adjust the clearance at the rear by bringing the backplanes forward - they could even protrude a little forward of the front panel without looking too odd.

I'm hoping to receive a SuperMicro AOC-USAS2-L8i (LSI2008-based, both IT and IR firmware available from SM) soon, so I look forward to posting about my experience with that.

After a little more hunting around the net, it appear that there are two different models of the iStar cage - the BPU-350-SA and the BPU-350-SATA. the unit in your review is the -SATA. The -SA is the 'other' model, without locks but (I presume) with aluminium handles. It also seems that there are two versions of the iStar trayless (or, perhaps, just a new version), BPN-350-SS and BPN-350V2-SS. I haven't discovered what the difference is between these two. Edit: The V2 appears to add SATA3 capability, and ventilation slots in the door. The V2 seems to be out of stack everywhere - one site says delivery expected in June. The other version also appears to be out of stock, with no further stock anticipated. There also appears to be two versions of the SM cage, the CSE-M35T-1 and the CSE-M35TQ. The TQ version adds 'SES-2 Enclosure Management'.

According to the iStar website, the BPU-350 is available with either black, blue, red or silver handles - however, I hadn't appreciated that they were now aluminium - this overcomes a significant drawback which I had read of in another review - that parts of the plastic were judged to be weak points. That bit of your review had me puzzled because some photos I've seen seem to show air vents in the front panel. In fact, I've just realised that the iStar website photos show two different designs of the tray fronts (some with key locks, some without) - presumably the old and new? Anyway, from what I now know, I'm pretty well decide to go for the iStar backplanes .... but do I want to venture into the unknown with the trayless BPN design, or stick with the (relatively) tried and tested BPU?

Okay, thanks - I will give those a try ... but with 4GB available, I'm surprised. However, with this info, it does look as though something is being greedy!: Memory Info (from /usr/bin/free) total used free shared buffers cached Mem: 3943140 3570284 372856 0 115252 3294348 -/+ buffers/cache: 160684 3782456 Swap: 0 0 0

Ah. okay - thanks for the explanation and reassurance!

I'm not sure what to make of the data collection never started/suspended, but I had exactly the same SMART report from my WD20EARS (green): S.M.A.R.T. error count differences detected after pre-clear note, some 'raw' values may change, but not be an indication of a problem 58c58 < 7 Seek_Error_Rate 0x002e 100 253 000 Old_age Always - 0 --- > 7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0 63c63 < 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 97 --- > 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 98 I believe that the load_cycle is normal, but I'm puzzled by the change in seek error rate parameters (although the error count is zero?).

There is definitely something odd going on. I'm running the preclear on the old parity drive now, prior to configuring it as an additional data drive. The preclear activity had reached the Post-Read when the family attempted to watch a movie (this time on disk1). The movie would only play for a few seconds and then just stop. I found that the Post-Read was reporting 85MB/s. I stopped the array, whereupon the Post-Read speed went up to 106MB/s. I restarted the array and the Post-Read speed remained over 100MB/s, and the movie would now play okay. In case it's relevant, I'm currently running unRAID 4.6-rc3.

That should certainly be true if there is no 'funny' below the application layer. However, in this case there is something strange going on and, if it is occurring at a low level in the system code, you cannot make any guarantees based on what you know is happening at the application level. Anyway, as an experiment, I stopped the array and then started the preclear. I then restarted the array and, to my relief, there were no increasing counts on disk2. In this state I have left the preclear running - now, after 12 hours, it is 75% through step 2. The parity, disk1 and disk2 drives are all spun down. It has even been possible to play movies from either data drive. When the preclear completes, my plan is to assign the new, 2TB, drive as parity and rebuild. Then I will preclear the old parity drive (1TB) before assigning it as disk3. I will be keeping a close eye on unexpected disk activity throughout the rest of this exercise.

... in theory! But the only devices currently active on the network are two Popcornhours, and my ubuntu desktop. If I kill the preclear, the reads on disk2 cease instantly, and the drive spins down after 15 minutes. [snip] I am convinced that the evidence all points to preclear reading disk2 (sdc) (which is mounted, and part of the array), while it is also reading the new drive (sdf). Of course, I have no hard proof that the new drive is being read at all - there are no read/write counts reported in unMenu for the new drive, while it is unmounted/unassigned. However, the new drive does not spin down but, perhaps this means that there is no spin down command sent to an unassigned drive, rather than being an indication that the drive is being accessed? I have now rebooted the unRAID server. The new drive has now become sde but there are no other changes. The behaviour when running preclear is exactly the same. Memory Info (from /usr/bin/free) total used free shared buffers cached Mem: 3943140 583048 3360092 0 64204 311224 -/+ buffers/cache: 207620 3735520 Swap: 0 0 0 Spin up groups are turned on (I will try turning off), but each of my 5 drives is reporting a different host. Okay, I will try some experiments in those areas. As things stand, I'm frightened to add the new drive to the array in case formatting/preparing it will write to the wrong drive. Also, I'm not comfortable about playing with drive assignments, in case I lose data.

... in theory! But the only devices currently active on the network are two Popcornhours, and my ubuntu desktop. If I kill the preclear, the reads on disk2 cease instantly, and the drive spins down after 15 minutes. If I then try playing a movie on the Popcornhour, it plays perfectly. If I restart the preclear, the movie stops playing within 30 seconds. Even if I then turn the Popcornhour off, the reads on disk2 continue as before. When I then kill the preclear again, the reads on disk2 cease, and the drive spins down again after 15 minutes! I am convinced that the evidence all points to preclear reading disk2 (sdc) (which is mounted, and part of the array), while it is also reading the new drive (sdf). I'm not sure whether there is a connection, but it might be worth pointing out that I also have the problem that nfs activity on the cache drive actually performs the operations on disk2!

Right, prudence dictates that I should terminate the preclear before it gets to a writing phase, until I get a better idea as to what is going on here.

I'm a little concerned that, during the pre-read, with no other device accessing unRAID (as far as I am aware), disks 1 and 2 are not being allowed to spin down, and are experiencing something in the order of 4000 reads a minute. All of the array disks are showing status green, and the parity has now spun up for no apparent reason. If the preclear is reading from more than one disk, is it going to start writing to more than one disk?

I've just connected up my new WD20EARS (with jumper installed), and started running the preclear script on it. I had understood that the raison d'etre for preclear was that the system should still be usable while the new disk was being prepared. However, I'm finding that there is insufficient resource for an HD movie file to be played while the preclear is in progress ... at least I presume that is what the problem is. The movie will start playing, but then fail after a few seconds - this is happening while attempting to play on my ubuntu desktop machine and on my Popcorn Hour. Is this expected? I'm running the preclear on a telnet session from ubuntu. After 40 minutes, it is 10% into the Pre-Read, reporting transfer rates of up to 110MB/s. Now, I'm sure that there is minimal network traffic being generatd by the preclear/telnet, so I guess that the restriction is on the disk interface/controller, or the data bus. Is there a way to ensure that normal array activity has precedence over the preclear, so that I can play a movie