From: Bakul Shah <bakul@bitblocks.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] wstat and atomic directory change
Date: Thu, 5 Feb 2015 09:20:44 -0800 [thread overview]
Message-ID: <20150205172044.2055BB82A@mail.bitblocks.com> (raw)
In-Reply-To: Your message of "Thu, 05 Feb 2015 08:20:30 PST." <e7e7a4528399904fac7e4b50d2098d80@brasstown.quanstro.net>
On Thu, 05 Feb 2015 08:20:30 PST erik quanstrom <quanstro@quanstro.net> wrote:
> > All this reflections arise from the search for an orthodox way to change
> > the tree structure of a synthetic filesystem.
> > Moving large real files is not my actual issue here. I'm wondering for a
> > synthetic filesystem in which, when you move a folder in a special
> > directory, something magic happens.
> > As far as I can see, it is not possible with a 9p2000 fileservice, is it?
>
> i don't see why you can't make a magic directory that works that way.
i agree with you that the magic is upto the fileserver to
provide but more generally, i think it would be an interesting
experiment for Giacomo Tesio to try to extend 9p. attempting
to extend something is a great way to learn. Tmove of files on
the same real FS can save a lot of unnecessary traffic. Tmove
of dirs can save some traffic too. of course either type of
move must be allowed to fail and must fail without any damage
if an atomic move is not possible. i think unix and plan9
design reflects choices available in 70s & 80s and it
certainly makes sense for someone not burdened with that
history to reexamine the design choices. machines are much
faster now so micro efficiency is less critical but latency is
more so. and storage capacities have grown much faster than
network bandwidth so opportunities for flinging less data
about should be looked at. the unification of synthetic and
real filesystems seems rather constraining now. storage is
used much more creatively now and may be distributed. can
there a generalized protocol for distributed storage? lots of
ideas to play with!
next prev parent reply other threads:[~2015-02-05 17:20 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-30 11:21 Giacomo Tesio
2015-01-30 14:13 ` erik quanstrom
2015-01-30 15:59 ` Giacomo Tesio
2015-01-30 20:19 ` Joel C. Salomon
2015-01-30 22:49 ` Anthony Sorace
2015-02-03 8:53 ` Giacomo Tesio
2015-02-03 9:04 ` Quintile
2015-02-04 3:51 ` erik quanstrom
2015-02-04 8:28 ` Giacomo Tesio
2015-02-04 14:06 ` erik quanstrom
2015-02-04 14:29 ` Giacomo Tesio
2015-02-04 16:30 ` Skip Tavakkolian
2015-02-04 19:23 ` erik quanstrom
2015-02-04 21:24 ` Giacomo Tesio
2015-02-05 4:13 ` lucio
2015-02-05 8:21 ` Giacomo Tesio
2015-02-05 8:37 ` Giacomo Tesio
2015-02-05 8:59 ` lucio
2015-02-05 8:54 ` lucio
2015-02-05 16:13 ` erik quanstrom
2015-02-05 4:15 ` lucio
2015-02-05 16:20 ` erik quanstrom
2015-02-05 16:46 ` Giacomo Tesio
2015-02-05 17:22 ` Skip Tavakkolian
2015-02-05 17:20 ` Bakul Shah [this message]
2015-02-05 4:26 sl
2015-02-05 4:26 sl
2015-02-05 8:08 ` Giacomo Tesio
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=20150205172044.2055BB82A@mail.bitblocks.com \
--to=bakul@bitblocks.com \
--cc=9fans@9fans.net \
/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).