From: "Skip Tavakkolian" <fst@centurytel.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Archiving appliance
Date: Fri, 11 Jul 2003 13:22:16 -0700 [thread overview]
Message-ID: <1efd792a3ee90e6dd21ffbb41efc51e5@centurytel.net> (raw)
In-Reply-To: <Pine.LNX.4.44.0307110853220.13208-100000@fbsd.cpsc.ucalgary.ca>
One of my clients recently had an RFC for a document management
system. The process was well underway before I got there. Had I been
there early enough, it would have been worthwhile to propose a Plan9
solution for about a quarter of the average price from other vendors.
I went through a rough cost estimate exercise. One chunk of the effort
would have to go to maturing SMB and NFS servers, and adding in a
snapshot-on-change feature; Another would be to build an automatic
mechanism for indexing of the content and correlating it with
fossil/venti snapshots.
I think this would be the same issue for caching servers. Relating
what the user is looking for with a snapshot will be the key.
Maybe that is what rob is working on at google. maybe not.
> I'll go first, hopefully other can correct me.
>
> there are several approaches you can take, rated here based on how good they
> sound to me (this also happens to be the same order, had they been rated by
> the 'impossibility to implement in the real world' scale):
>
> - replace NetApp with Fossil/Venti. it really sounds like a good idea. a
> fossil/venti combination gives you exactly the same thing as a NetApp, but
> it has the archival option (dumps), and no NFS as a bonus. (how about
> speed?)
>
> cons: you need to teach your client applications to speak 9p
>
> - teach NetApp to speak 9p (or just to talk directly to the Venti) and have
> it store dumps there every night. good thing about this is that your
> applications don't need to know 9p, and could still access
> /n/dump/yyyy/mmdd/-style archives.
>
> cons: quite a bit. teaching NetApp to talk 9p may be quite the task. you
> still have NFS.
>
> - have a fossil/venti/nfs server in the back, where netapp dumps the data.
> that way you don't have to change anything but just add functionality.
>
> cons: you still have to deal with NFS, and Plan 9 does not a good NFS
> server make, I've heard.
>
> andrey
>
> ps: this list is non-exhaustive, it is just what I could think of during
> morning coffee. it also could be totally wrong.
>
> On 11 Jul 2003, Anders Soendergaard wrote:
>
>> Hi Plan 9 folks.
>>
>> I'm involved in a project that is to produce archiving
>> services to our company. Besides policies and procedures
>> we need a box with a lot of disks.
>>
>> I thought it would be fun to see if it was possible to
>> use Venti/Fossil for that purpose. My wet dream is to make
>> some sort of Plan 9 archiving appliance that you would dump
>> your data on from our NetApp's. We would then have several
>> of those appliances on different sites that replicated their
>> local content to the others.
>>
>> The first obstacle is to get the data from the NetApps to
>> the Venti/Fossil server. This might be through a gateway
>> of some sort.
>>
>> Has anybody tried something like that? Or is it a waste
>> of time to try this approach?
>>
>>
>> Best regards,
>>
>>
prev parent reply other threads:[~2003-07-11 20:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1057912039.10046.16.camel@coffin01>
2003-07-11 15:06 ` andrey mirtchovski
2003-07-11 15:16 ` ron minnich
2003-07-11 20:22 ` Skip Tavakkolian [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1efd792a3ee90e6dd21ffbb41efc51e5@centurytel.net \
--to=fst@centurytel.net \
--cc=9fans@cse.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).