From: forsyth@vitanuova.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] QID reference
Date: Sun, 4 Nov 2001 19:19:56 +0000 [thread overview]
Message-ID: <20011104191917.40FA3199B5@mail.cse.psu.edu> (raw)
[-- Attachment #1: Type: text/plain, Size: 1814 bytes --]
it is discussed by intro(5):
... The qid
represents the server's unique identification for the file
being accessed: two files on the same server hierarchy are
the same if and only if their qids are the same. (The
client may have multiple fids pointing to a single file on a
server and hence having a single qid.) The eight-byte qid
fields represent two four-byte unsigned integers: first the
qid path, then the qid version. The path is an integer
unique among all files in the hierarchy. If a file is
deleted and recreated with the same name in the same direc-
tory, the old and new path components of the qids should be
different. Directories always have the CHDIR bit
(0x80000000) set in their qid path. The version is a ver-
sion number for a file; typically, it is incremented every
time the file is modified.
it's quite important that Qid.path be unique for active
files in the same hierarchy (identified by type and dev),
otherwise bind and mount will malfunction because they ultimately
depend on Qid values via the mount table. for that reason,
exportfs(4) resolves qid.path clashes that can occur when it
exports a hierarchy with binds and mounts within it.
(the importing system will expect Qid.path to be unique
in the hierarchy it sees, but the original type and dev
that separated the Qid.path spaces on the exporting system
are not seen on the importing system.)
Qid.vers is less critical but is used by the kernel
file cache for mounted file systems, and by cfs(4) and others.
devices often don't maintain it; support elsewhere is a little patchy,
but kfs and the file server kernel do support it, as does env(3).
[-- Attachment #2: Type: message/rfc822, Size: 1405 bytes --]
To: 9fans@cse.psu.edu
Subject: [9fans] QID reference
Date: Sat, 3 Nov 2001 15:37:08 -0500
Message-ID: <20011103203528.558E5199B5@mail.cse.psu.edu>
What's the idea behind the vers/path in the 9P qid? Is path
just a serial number? Is there a reference to the literature?
Brantley Coile
next reply other threads:[~2001-11-04 19:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-04 19:19 forsyth [this message]
-- strict thread matches above, loose matches on Subject: below --
2001-11-04 6:20 rob pike
2001-11-03 20:37 bwc
2001-11-03 21:15 ` Boyd Roberts
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=20011104191917.40FA3199B5@mail.cse.psu.edu \
--to=forsyth@vitanuova.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).