From owner-freebsd-questions Mon Nov 26 23:13:38 2001 Delivered-To: freebsd-questions@freebsd.org Received: from mail.freebsd-corp-net-guide.com (mail.freebsd-corp-net-guide.com [206.29.169.15]) by hub.freebsd.org (Postfix) with ESMTP id 2DE2D37B405 for ; Mon, 26 Nov 2001 23:13:23 -0800 (PST) Received: from tedm.placo.com (nat-rtr.freebsd-corp-net-guide.com [206.29.168.154]) by mail.freebsd-corp-net-guide.com (8.11.1/8.11.1) with SMTP id fAR7AhR46649; Mon, 26 Nov 2001 23:10:43 -0800 (PST) (envelope-from tedm@toybox.placo.com) From: "Ted Mittelstaedt" To: "Robert Suetterlin" Cc: Subject: RE: storing 10TB in 494x435x248mm, with power of 200W (at 28VDC) (was: why are You asking here) Date: Mon, 26 Nov 2001 23:10:41 -0800 Message-ID: <000001c17712$9f775880$1401a8c0@tedm.placo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <20011126120431.C1170@robert2.mpe-garching.mpg.de> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Importance: Normal Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >-----Original Message----- >From: owner-freebsd-questions@FreeBSD.ORG >[mailto:owner-freebsd-questions@FreeBSD.ORG]On Behalf Of Robert >Suetterlin >Sent: Monday, November 26, 2001 3:05 AM >To: Ted Mittelstaedt >Cc: freebsd-questions@FreeBSD.ORG >Subject: storing 10TB in 494x435x248mm, with power of 200W (at 28VDC) >(was: why are You asking here) > > >Hello Ted, > >thanks for discussing this problem so far, it really helps making up >my mind when I get different opinions on this topic. > your welcome > >[...] >> >> 3) What exactly is a HSM going to do for you? >> >HSM is useful if You have a hirarchy of storage with different >> >qualities. >> That's what I said. >> >> You indicated that your doing archival only - ie: "one quality" in your >> terms. Is this not true? >[...] >Sorry. I seem to keep to much of my thoughts to myself: A data rate of >260MByte per second, the size and power limits seemed to prohibit real >time compression. (We need 'lossless' compression, and there has not >been an algorithm selected / designed yet.) The only people I know of in the industry that have the experience with on-the-fly high compression that might possibly help you is Stac Electronics, they have some patented algorithms that could possibly be scaled up to what you want. I would not discount on-the-fly compression if I were you. Even if you got a small amount of compression it would reduce the storage needs tremendously. It's an option that because the benefits are so large it's worth exploring. >I concluded we would have to >record the 45 Minute 260MB/s databursts to some kind of fast >intermediate storage (for example RAM or Solid State Disks, etc.). Then >we could spend some time (e.g. a day) on transferring that data to >permanent storage and possibly reprocessing / compressing offline. >Sometimes experimentalists would like to read some 'old' data back into >the machinery to do a little analysis online (via telescience) before a >shuttle takes the 'tapes' back to earth. In addition the system should >'automatically' record metadata and implement redundancy. > Would the experimentalists really need the high resolution to do online analysis? What about recording 2 databursts at the same time - a high resolution one and a low resolution one? The low resolution one would spool off to temp storage and perhaps only be saved for a few days, or downloaded Earthside. That might be enough to figure out where the interesting things are. >To me there seemed to exist two possible solutions (except for the >completely handmade thingy): 1) a kind of batchmode system running >{record, reprocess, store} and {reread, reprocess, manipulate} jobs that >would be similar to a VCR and would require implementing metadata and >redundancy 'by hand'. 2) or using some kind of storage manager, that >could handle these tasks and manage resources 'automatically'. > Well, I think you got 2 redundancy needs here. First is what you would call data integrity problems, that's what you want the metadata for, all it does is verify that the storage medium isn't trash. It's important for storage media like tape because tape is nowhere near got the critical reliability that you want. But, I'd pose the question, what if the storage medium were "perfect" or nearly so, would there be the same redundancy needs? The second redundancy is, well what happens if a shuttle on a return trip crashs and your tapes get disintegrated. >[...] >> >150TB of data per year. If there is a >> >shuttle mission each month, they will have to transport 10TB of data >> >each time. >> So then have someone design an optical solution for you. >[...] >I have monitored the 'optical solutions' market for three years now and >I do not trust in them beeing able to deliver better data density than >magnetic media in the next ten years... but then I would be delighted if >they proved me wrong. >[...] >> >I also would like to use the >> >same general technique today that we will launch in five years (and then >> >use for up to ten more). So I would like to use standard hardware and >> >software solutions. These will most likely adept to the future >> >automatically. >> Any standard solution will be hopelessly obsolete 10 years from now and >> getting >> parts for it will cost astronomically. >[...] >You are completely right --- talking about fixed hardware. (I see that >my paragraph hints to such a thing.) Yet I thought about a combination >of software and hardware, where both could be upgraded independently >while still keeping standard interfaces available, and called that a >'standard solution'. I mean something like Intel CPU, PC Architecture >and *BSD. All have changed over the last ten years quite a lot. But >still I could run a software that would rely on 'standard' interfaces >(like files, ports, pipes, etc.) from ten years back on todays most >modern hardware and newest *BSD version. And the prices would even have >dropped. I would caution you about that. One of the poorest-kept secrets in computer hardware today is we have long since gotten into the area of diminishing returns in the "industry standard" Wintel architecture. There's a lot of future computer technology, like voice recognition, artificial intelligence, and so on that is going to require an order of magnitude more powerful computer hardware than what we got today. Microsoft and Intel both know it, and both of them are caught between a rock and a hard place. On one hand, they must break with the past and go to a totally new architecture to break away from the old IBM PC/XT limitations. On the other, if they do that then they redefine the market and in so doing open the door for a huge host of new competitors. But if they do nothing, then people are going to eventually stop buying new hardware and software except for replacement of failed electronics, and both of them will go out of business. I think we are seeing the warning shots across the bow now, the computer market is getting restless and is sending the message loud and clear that the same _old_ Wintel in a new box won't cut it anymore. They aren't buying anymore and it's hurting the entire technology sector. I suspect that in 10 years that computers are going to look very, very different than they do today with fundamentally different internal architectures. I hope that FreeBSD keeps up! >> >> Instead of attempting to get some sort of standard now, what you need >> to do is trust in the Capatalistic system to use whatever work your >> R&D budget creates and make commercial products out of it. Then 10 >> years from now such high-capacity arrays will cost $100 and be >> available from Costco. Attempting to use off-the-shelf products now >> does not help anybody realize any R&D leverage from your budget - >> which is the entire point of the money spent on ISS. >> >> The dollars are available from the hardware manufacturers. Your >> project would have high marketing value to them. Leverage that value! >Yes. Maybe that is the best strategy to go with... and it would be in >the best spirit of the ISS project. Considering my 'spare' time and all >I heard in several discussions this will be a likely >solution. Well I'm sure that we would be interested in future news here on this espically if it involves FreeBSD. Keep us apprised! Ted Mittelstaedt tedm@toybox.placo.com Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message