Changeset 5045 for trunk/Nebulous/docs

Timestamp:

Sep 13, 2005, 2:46:58 PM (21 years ago)

Author:

jhoblitt

Message:

update

Location:

trunk/Nebulous/docs

Files:

• design.txt (modified) (3 diffs)
• requirements.txt (modified) (3 diffs)

trunk/Nebulous/docs/design.txt

@@ -1 +1 @@
 # Copyright (C) 2004-2005  Joshua Hoblitt
 #
-# $Id: design.txt,v 1.2 2005-09-02 04:20:29 jhoblitt Exp $
+# $Id: design.txt,v 1.3 2005-09-14 00:46:58 jhoblitt Exp $
 
 Overview
@@ -23 +23 @@
 technologies can be improved upon.
 
+A centralized server model was used to allow efficient use of 'like' searches
+on storage object names.  The current 'best' technique for a distributed
+metadata store is with distributed hash tables.  Unfortunately, no widely
+available DHT implementation allows 'like' searches on key names.
+
 [1] Multiple Nebulous servers should be possible via database replication.
 [2] A future version of Nebulous may include it's own data transport layer
@@ -31 +36 @@
 
 The Nebulous Server and clients communicate via the SOAP protocol.  Since SOAP
-is platform independent this allows native Nebulous client to be written in a
+is platform independent this allows native Nebulous clients to be written in a
 variety of languages.  With in the Nebulous Server itself the IPC mechanism is
 abstracted to allow ether multi-protocol support or complete replacement of

trunk/Nebulous/docs/requirements.txt

@@ -1 +1 @@
 # Copyright (C) 2004  Joshua Hoblitt
 #
-# $Id: requirements.txt,v 1.1.1.1 2004-12-22 02:16:23 jhoblitt Exp $
+# $Id: requirements.txt,v 1.2 2005-09-14 00:46:01 jhoblitt Exp $
 
 - store all image data aquired during the first two years of PS1's
@@ -7 +7 @@
 
 - injest new data from the summit at the same rate it is produced when
-  operating at a cadence of 40s between integrations.  Approximately 400Mb/s.
+  operating at a cadence of 40s between integrations.  Approximately 400Mb/s
+  and 64 files/integration.
 
 - support phase 1 & 2 processing. x files per t_min
@@ -14 +15 @@
 
 - support accessing small blocks of a file (ie., seek)
+
+- tolerate partal system failures without data loss
+
+- execeedly efficent use of both disk and network I/O
 
 what are the science drivers for these 3?