9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
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

             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).