I was thinking about making a miniature xserve with sd cards and disk utility's built in RAID functions. Would this be possible, and where could I get the (14) sd card readers (without the cases) ? Also, should I do what the iPod shuffle RAID project did with a hub or should I try to use my own firewire/usb2 controllers?
I don't know the data transfer rates of SD cards, but this might affect your choice. Chances are though, you'll get the best rates if you distribute cards across your built in busses. Since you'll need a USB for your keyboard and mouse (unless you use bluetooth), you might be wiser to use firewire readers. 7 on each port daisy chained together.
I like this idea. You should build a mini Xserve case for it too. If you disassemble the Mini and lay the optical and hard drives nect to the logic board, you should end up with a 1U server the size of a switch or hub.
When the Mini first came out, I dreamed of getting several of them and installing the logic boards in a 1U server case........
I believe you misunderstood me. I was talking about putting a bunch a SD readers into a miniature xserve RAID case (I'd make the case). It had nothing to do with the Mac Mini.
Kinda of wondering why would you need 14 SD card readers? Couldn't you get higher capacity and better speed at a cheaper price all things totalled by using just a couple of laptop hard drives (or smaller) over FireWire.
Flash cards are slow no matter what speed they are. He needs fourteen to get the speed up from what I can tell. To truely get it to a high speed you need sepearte usb controllers for each one. That would be an issue as far as I can tell. I would use three seperate usb pci cards with four on each one. Could be pretty cool mod. Good luck.
This message made me think... Why couldn't it be possible (were the powers at the helm willing to enduldge such a mess) to allow more flexible configurations of mixed hardware types? Why can't differing drive capacities work or raiding over different physical bus types (like a PCI drive in RAID with an iPod shuffle for a really extreme example, or like a SATA internal with a FireWire external for a more common practical use example). The truth is, nomatter how slow the slowest drive is, if done correctly the way I envision it, since the fastest drive can't go any faster than it can, adding a slower drive to absorb a disproportionate, smaller share of the work nomatter what would reduce the time to read or write as compared to if the faster drive were off on its own handling the entire read or write. It is possible to missmatch drives over different buses or different capacities--all other factors being equivalent with my idea, although you would be always struggling with lost drive capacity on drives that are on relatively slower bus connections as a trade-off to keep drives in synchronous write simplicity without some inordinately new complex asynchronous RAID scheme which allows different drives to write for longer periods of time in order to do their bit-equivalent share. That asynchronous write time same write-length idea would be lame because it would penalize overall per file transaction times as compared to synchronous--although it would allow to keep the option for redundant bit parity checking and drive recovery were all drives the same size.
If you change the rules and implementat a new kind of software RAID category (in theory) which does not work on an "each drive gets one bit per clock" kind of equal distribution mentality, but rather "virtualizes" the drives somewhat by not require writing equal numbers of bits to all drives--yet in a synchronized fashion---you could use a fixed performance or capacity based ratio to distribute bits or groups of bits on a disporportionate basis between drives (disproportionate only in terms of how many bits each drive gets to hold). While you would lose your ability to restore a lost volume automatically like some RAIDs implement using parity bit checks (because parity checking in this scenario would not be possible anymore as currently implemented) you would gain the ability to implement a RAID that's more flexible in terms of not perfectly matched hardware. Creating and managing a mismatched RAID theoretically could be done for either unequivalent bus drive throughput speeds or unequivalent drive storage capacities by means of fixed ratios (but not both kinds of differences at once using my stratedgy, the ratios would interplay and it wouldn't work.) Using a sort of qualitative analysis at the point of establishing the RAID the controlling software would analyze either the ratio of capacity difference between drives as compared to the largest drive deployed, or the ratio of average actual throughput to each drive as compared to the fastest drive found and thus create a new, simple method of structuring a RAID not based on equal division of bits, but a simplistic internal reference ratio which remembers the relative ratio of either the capacity differentials or connection throughput differences to each drive. Files are under this system stored in small packets per time frame where the packet size is determined by the write-time of the slowest drive connection to perform a one byte write operation and how much time that took. All other drives will use the ratio scheme to determine the relative number of bits they can write per packet given the same time frame. Thus faster drives will be kept happy because per slowest bus clock cycle, they are writing as much information as they are rated capable of at the time the ratios are established. Read ratios will for practicle reasons have to be assumed to be similar to write ratios. If not, an asynchronous option would be deployed for reading only which allows connections where read and write times are disproportionate to that of other connections to catch-up. This somewhat simplistic approach would not create much extra overhead really.
This however leads to a new problem where the different speeds are allowed. To use a simplistic fixed ratio scheme only and not some kind of drastic indexing service to track down bits that go on variable ratios leads to a situation where space is wasted on equivalent capacity but slower speed ratiod drives as faster drives will be able to fill to capacity (if same capacity) at an uneven rate. For connections with large speed differences, the capacity loss would be equivalent in percentage mind you to the percentage of difference in speed.. so a drive that only runs maximumly 10% as fast will only get to use its first 10%, wasting completely the last 90%.. hence probably the reason why nobody has attempted such a thing. On the other hand, if the drive that's slowest was only about 10% of the capacity anyways, then this loss wouldn't be a loss and you just took 10% of the workload off your largest drive for free....
is the point of the mod to make a sweet looking mini Xserve RAID or are you looking at this because you have a bunch of SD cards laying around? If its to make a tiny little RAID that looks just like a regular Xserve RAID then the SD cards will work fine, but I'm pretty sure you won't be pleased with its performance regardless of whether you split them up over several PCI cards. I am reminded of the Shuffle RAID that you mention, and also of the http://ohlssonvox.8k.com/fdd_raid.htm floppy drive RAID.
:silly: FIXM I gave you a karma point for longest post ever<br><br>Post edited by: krusher117, at: 2005/12/18 21:49
YEAH! My first karma point on MacMod... 8-} Now, how many karma points do I need to collect before a mysterious shadowy figure who some people call "Steve" just on a whim happens to send me a brand new sparkley G6 just to see how I like it? heh..
(PS Don't tell anyone the longest post ever was originally twice as long, but I edited it down to half the original length when I decided it was wayy too long. Yup, whacked er back like a nasty little thorny hedge and hit submit. Poor submit... Such violence.. I don't know what came over me...) @='O
Previous Topic
Index
