9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "John E. Barham" <jbarham@jbarham.com>
To: 9fans@cse.psu.edu
Subject: [9fans] Distributed filesystems:  Plan 9 vs. Linux
Date: Sun, 29 Feb 2004 11:59:48 -0800	[thread overview]
Message-ID: <029c01c3fefe$95f0a430$6539a8c0@hpn5415> (raw)

I'm working w/ a system that stores 10's of thousands of high-definition
images per project (think movies).  Storing all of the files on a single
file server is not feasible (even w/ 3 x 1.8 TB arrays per Linux file
server) and even if it were possible would be sub-optimal from a network
standpoint since literally hundreds of image processing nodes could be
hitting the server simultaneously.

Keeping track of where the files for a particular project are physically
stored is a nuisance and it can be time-consuming to track down the location
of a particular file, esp. for some of the less technically minded users
(e.g., artists).  Our solution is to develop a virtual mapping service that
maps logical URLs (e.g., /project/shot/frame010000.tiff) to physical
location (e.g., /server10/home/user/project/shot/frame010000.tiff), but this
requires adding support to client applications to work properly.  Cumbersome
but still a lot cheaper than buying high-end dedicated storage solutions,
and even then we'd run out of space.  (We considered using HTTP redirection
but couldn't see how to make this work efficiently for PUT operations.)  It
occurred to me that Plan 9 has already solved this problem by being able to
(securely) mount remote filesystems and do a union on directories.  (Correct
me if I'm wrong, but IIRC creating a file in a unioned folder would add the
file to the original folder location.)

Even something as seemingly simple as collecting stats on drive usage per
server is a pain on Linux.  For the moment we're running du over ssh using
an expect style module in Python.  Again, Plan 9 would make that trivial
either by mounting the remote file server directly, or possibly running the
script after doing a cpu connection.

Anyway, it's a truism that the more powerful hardware gets (in both CPU
power and storage capacity) the more ways we find to use it to capacity, so
mechanisms that Plan 9 provides to present a seamless view of distributed
resources are becoming more necessary, not less.

    John

P.S.  Forgive me if I'm hazy on the details of the Plan 9 commands, but the
website appears to be down at the moment...



             reply	other threads:[~2004-02-29 19:59 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-29 19:59 John E. Barham [this message]
2004-02-29 19:38 ` andrey mirtchovski
2004-02-29 23:32   ` boyd, rounin
2004-03-01 17:27   ` John E. Barham
2004-03-01 17:37     ` matt
2004-03-02  4:10       ` Martin C.Atkins
2004-02-29 20:26 ` Jeff Sickel
2004-03-01 17:14   ` John E. Barham
2004-03-01 18:26     ` Jeff Sickel
2004-03-01  1:56 ` James Horey
2004-03-01  2:04   ` Geoff Collyer
2004-03-03  7:46 YAMANASHI Takeshi

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='029c01c3fefe$95f0a430$6539a8c0@hpn5415' \
    --to=jbarham@jbarham.com \
    --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).