From: Arjan van de Ven <arjan@linux.intel.com>
To: Matthew Wilcox <matthew@wil.cx>
Cc: Valerie Henson <val_henson@linux.intel.com>,
Ric Wheeler <ric@emc.com>,
linux-fsdevel@vger.kernel.org
Subject: Re: topics for the file system mini-summit
Date: Thu, 01 Jun 2006 14:53:29 +0200 [thread overview]
Message-ID: <447EE349.3040008@linux.intel.com> (raw)
In-Reply-To: <20060601124517.GC32143@parisc-linux.org>
Matthew Wilcox wrote:
> On Wed, May 31, 2006 at 08:24:18PM -0700, Valerie Henson wrote:
>> Actually, the continuation inode is in B. When we create a link in
>> directory A to file C, a continuation inode for directory A is created
>> in domain B, and a block containing the link to file C is allocated
>> inside domain B as well. So there is no continuation inode in domain
>> A.
>>
>> That being said, this idea is at the hand-waving stage and probably
>> has many other (hopefully non-fatal) flaws. Thanks for taking a look!
>
> OK, so we really have two kinds of continuation inodes, and it might be
> sensible to name them differently. We have "here's some extra data for
> that inode over there" and "here's a hardlink from another domain". I
> dub the first one a 'continuation inode' and the second a 'shadow inode'.
nonono
the "hardlink" is in a directory inode, and that *directory* has a continuation
for the dentry that constitutes the hardlink. But that dentry is "local" to the data.
so the directory ends up being split over the domains
> Another advantage to this is that inodes never refer to blocks outside
> their zone, so we can forget about all this '64-bit block number' crap.
exactly the point!
next prev parent reply other threads:[~2006-06-01 12:53 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-25 21:44 topics for the file system mini-summit Ric Wheeler
2006-05-26 16:48 ` Andreas Dilger
2006-05-27 0:49 ` Ric Wheeler
2006-05-27 14:18 ` Andreas Dilger
2006-05-28 1:44 ` Ric Wheeler
2006-05-29 0:11 ` Matthew Wilcox
2006-05-29 2:07 ` Ric Wheeler
2006-05-29 16:09 ` Andreas Dilger
2006-05-29 19:29 ` Ric Wheeler
2006-05-30 6:14 ` Andreas Dilger
2006-06-07 10:10 ` Stephen C. Tweedie
2006-06-07 14:03 ` Andi Kleen
2006-06-07 18:55 ` Andreas Dilger
2006-06-01 2:19 ` Valerie Henson
2006-06-01 2:42 ` Matthew Wilcox
2006-06-01 3:24 ` Valerie Henson
2006-06-01 12:45 ` Matthew Wilcox
2006-06-01 12:53 ` Arjan van de Ven [this message]
2006-06-01 20:06 ` Russell Cattelan
2006-06-02 11:27 ` Nathan Scott
2006-06-01 5:36 ` Andreas Dilger
2006-06-03 13:50 ` Ric Wheeler
2006-06-03 14:13 ` Arjan van de Ven
2006-06-03 15:07 ` Ric Wheeler
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=447EE349.3040008@linux.intel.com \
--to=arjan@linux.intel.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=ric@emc.com \
--cc=val_henson@linux.intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.