From: roger peppe <rogpeppe@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] 9p vs http
Date: Mon, 15 Nov 2010 21:38:23 +0000 [thread overview]
Message-ID: <AANLkTi=paBhVA1=g_WU6674z9RHqkczkMJ5p1bRgLcRi@mail.gmail.com> (raw)
In-Reply-To: <f8ff7a4432b9863d1a17f11648c2b370@coraid.com>
On 15 November 2010 19:29, erik quanstrom <quanstro@labs.coraid.com> wrote:
>> if you mount onto one, you'll see the mounted files
>> on the other.
>>
>> gorka was talking about identifying files from their qid.
>> the version number doesn't help in identifying the file -
>> someone could have modified the file 35 times between
>> stats.
>
> what definition of "file" are you using? you've rejected the
> definition that "file" is identified uniquely by path.
i've only rejected that definition based on observation - intro(5)
does state that the qid path should be unique amongst all files
in the hierarchy, but that's a difficult ideal to live up to
when you're multiplexing filesystems.
>> anyway, even if the version number is the same, the contents
>> may be different.
>
> i claim that a fs with this behavior would be broken. intro(5)
> seems to agree with this claim, unless i'm misreading.
you're right - fossil is broken in this respect, as is exportfs
{cd /mnt/term/dev; ls -lq | sort} for a quick demo.
the only correct way that i can see for a multiplexing fs to avoid this breakage
is the keep track of every qid that it sees, allocating a new qid of its
own for each one. no-one does this because it can use unbounded
memory. instead they map qids on open, because relatively
few files are opened.
that's why i was suggesting a "big enough" qid space as another
possibility. an alternative might be to remove qids from the
Dir structure entirely, returning them only on walk and open.
next prev parent reply other threads:[~2010-11-15 21:38 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-15 3:25 Sam Watkins
2010-11-15 4:20 ` John Floren
2010-11-15 4:26 ` Bruce Ellis
2010-11-15 5:16 ` Sam Watkins
2010-11-15 5:26 ` John Floren
2010-11-15 14:09 ` Gorka Guardiola
2010-11-15 14:15 ` Gorka Guardiola
2010-11-15 15:37 ` roger peppe
2010-11-15 16:45 ` C H Forsyth
2010-11-15 16:37 ` roger peppe
2010-11-15 16:48 ` erik quanstrom
2010-11-15 17:02 ` roger peppe
2010-11-15 19:29 ` erik quanstrom
2010-11-15 21:38 ` roger peppe [this message]
2010-11-16 1:18 ` erik quanstrom
2010-11-16 12:12 ` roger peppe
2010-11-16 15:56 ` Charles Forsyth
2010-11-16 16:04 ` erik quanstrom
2010-11-16 16:32 ` Charles Forsyth
2010-11-16 17:11 ` roger peppe
2010-11-15 15:44 ` David Leimbach
2010-11-15 15:55 ` Venkatesh Srinivas
2010-11-15 15:57 ` David Leimbach
2010-11-15 18:44 ` Russ Cox
2010-11-15 19:00 ` Dan Adkins
2010-11-15 22:18 ` Yaroslav
2010-11-15 22:34 ` erik quanstrom
2010-11-16 12:42 ` Russ Cox
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='AANLkTi=paBhVA1=g_WU6674z9RHqkczkMJ5p1bRgLcRi@mail.gmail.com' \
--to=rogpeppe@gmail.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).