From: Bakul Shah <bakul@bitblocks.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] Q: moving directories? hard links?
Date: Sat, 16 Apr 2011 11:22:13 -0700 [thread overview]
Message-ID: <20110416182213.8E1D5B849@mail.bitblocks.com> (raw)
In-Reply-To: Your message of "Sat, 16 Apr 2011 17:33:39 -0000." <86d3km6qz0.fsf@cmarib.ramside>
On Sat, 16 Apr 2011 17:33:39 -0000 smiley@zenzebra.mv.com wrote:
> ron minnich <rminnich@gmail.com> writes:
>
> > If you look at what a hard link is, you'll realize why they are not in
> > Plan 9.
>
> It's not that obvious to me. A hard link is another name for a file,
> uniquely identified by <type,device,qid>. The effect of a hard link can
> be simulated with bind, but requires managing a list of excetions (one
> bind for each "link"). If the binding were done server-side, there
> would need to be some additional protocol element (perhaps a Tbind
> request) to add another name to a file. The semantics of Tbind could
> meaningfully be extended to all types of files, not just disk files.
You are focusing on "how" to implement it, not "why".
Ask yourself *why* do you need it. Is it just convenience
(what you are used to) or is there something you do that
absolutely requires hard links? Next compare the benefit
of hardlinks to their cost. It is worth it?
Hard links force certain design choices and make things more
complex. For instance, you have to store the "inode"
(metadata) of a file separate from its name(s) so if you lose
all of its names, you need a way to garbage collect the object
(or add a name) -- what fsck does. If there is just one name,
you can store the metadata along with the name -- a simpler
choice; you don't need to allocate a separate disk area for
inodes.
Next, you can only hardlink on the `same device' so now the
underlying device is no longer transparent (i.e. something you
can ignore) and you can't be sure if
ln <path1>/a <path2>/b
will work. A more complex user model.
Next, Unix typically only allows hardlinking of files and not
directories (to avoid creating accidental loops -- detecting
loops is considered more complex for some reason). So more
restrictions.
Next, the concept of hardlink is not particularly useful or
doesn't even make sense for synthetic filesystems (such as
devices or environment or basically anything that can benefit
or be more easily accessed given a collection of names and
often these names have special meanings). What would it even
mean if you allowed "ln /proc/123 /proc/324"? So even in unix
where special filesystems are allowed such operations are
banned. So more restrictions.
A more useful concept is that of a `view' on a collection of
things rather than hardlinking individual files. bind/mount
already give you that.
Coming from a Unix environment you have learned to live with
the complexity of and restrictions on hardlinks and very
likely you think of filesystem names as almost always
referring to files that store data or directories. "Unlearn"
unix rather than try to recreate it in Plan9!
next prev parent reply other threads:[~2011-04-16 18:22 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-16 2:36 smiley
2011-04-16 2:40 ` Jacob Todd
2011-04-16 4:22 ` ron minnich
2011-04-16 16:53 ` erik quanstrom
2011-04-16 17:33 ` smiley
2011-04-16 17:51 ` erik quanstrom
2011-04-21 15:32 ` smiley
2011-04-21 15:43 ` ron minnich
2011-04-16 18:22 ` Bakul Shah [this message]
2011-04-21 15:44 ` smiley
2011-04-21 15:49 ` ron minnich
2011-04-21 16:54 ` Bakul Shah
2011-04-21 20:17 ` Richard Miller
2011-04-21 21:10 ` Bakul Shah
2011-04-21 22:41 ` erik quanstrom
2011-04-21 23:17 ` ron minnich
2011-04-21 23:54 ` Bakul Shah
2011-04-21 23:55 ` erik quanstrom
2011-04-22 0:01 ` ron minnich
2011-04-22 0:04 ` erik quanstrom
2011-04-22 8:03 ` Bakul Shah
2011-04-22 8:27 ` dexen deVries
2011-04-22 13:05 ` erik quanstrom
2011-04-22 17:47 ` Bakul Shah
2011-04-24 18:58 ` erik quanstrom
2011-04-16 18:03 ` Richard Miller
2011-04-16 18:17 ` Skip Tavakkolian
2011-04-16 18:56 ` Rob Pike
2011-04-18 9:08 ` Aharon Robbins
2011-04-18 12:41 ` erik quanstrom
2011-04-18 12:59 ` Lucio De Re
2011-04-18 13:00 ` erik quanstrom
2011-04-18 13:11 ` Lucio De Re
2011-04-23 3:48 ` Ethan Grammatikidis
2011-04-21 9:22 ` Balwinder S Dheeman
2011-04-16 16:58 ` erik quanstrom
2011-04-19 15:36 ` Charles Forsyth
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=20110416182213.8E1D5B849@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).