Re: Things that Longhorn seems to be doing right

From: Brian Beattie (beattie_at_beattie-home.net)
Date: 11/03/03

  • Next message: Ihar 'Philips' Filipau: "Re: How provoke call stack trace" 
    To: Valdis.Kletnieks@vt.edu
Date:	03 Nov 2003 14:35:35 -0500

    On Sun, 2003-11-02 at 12:15, Valdis.Kletnieks@vt.edu wrote:
    > On Sun, 02 Nov 2003 08:11:32 EST, Brian Beattie <beattie@beattie-home.net> said:
    >
    > > for storage might be feasible soon. The idea is that you have a
    > > permanent store, using raid or raid-like redundancy and file versioning
    > > so that nothing is ever deleted, you just keep adding drives and
    > > replacing those that fail. Of course you'd need some geographic
    > > diversity and a way for storage to migrate to newer "file stores" to
    > > really work, but just think, no more backups to fail...ever!
    >
    > This may be very nice for the high end, but getting "geographic diversity"
    > means you have to get space in a colo of some sort (unless you're a big enough
    > site that you have another building of your own at least a mile or two away),
    > and bandwidth between the two sites.

    I don't know about anytime soon and it woudl be a real paradyne(sp?)
    shift. As it is right now home many home users do backups ate all. The
    replication could well be rather low bandwidth, more to CYA in the event
    of a fire of natural disaster, and really a secondary issue. What
    intriques me, is the notion of a permanent file store that is never
    deleted.

    I have no idea if this will every make sense, but I notice, that I
    always have more disk than will fit on any backup media I can afford.
    So this is really just a "what if?" thought. 

    -- 
Brian Beattie            | Experienced kernel hacker/embedded systems
beattie@beattie-home.net | programmer, direct or contract, short or
www.beattie-home.net     | long term, available immediately.
"Honor isn't about making the right choices.
It's about dealing with the consequences." -- Midori Koto
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
  • Next message: Ihar 'Philips' Filipau: "Re: How provoke call stack trace"

    Relevant Pages

    • Re: [patch 8/8] PCI Error Recovery: PPC64 core recovery routines
      ... >> Of course, we'll possibly end up with a different ethX or whatever, but ... Its a distinct problem; ... > is a serious issue for home users and even more so for enterprise-class ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: In-kernel Gopher server
      ... >> Maybe the wristwatch example was a bit extreme, ... >> system with very low bandwidth for connectivity? ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: In-kernel Gopher server
      ... > system with very low bandwidth for connectivity? ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)