From: "Jörn Engel" <joern@logfs.org>
To: arnd@arndb.de
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, hch@lst.de
Subject: Re: [RFC 2/7] cramfs: create unique inode numbers
Date: Sun, 1 Jun 2008 18:50:48 +0200 [thread overview]
Message-ID: <20080601165048.GC13094@logfs.org> (raw)
In-Reply-To: <20080531153510.692084580@arndb.de>
On Sat, 31 May 2008 17:20:15 +0200, arnd@arndb.de wrote:
>
> This changes the inode number in cramfs to be based on
> the location of the dentry instead of the file, in order
> to make inodes unique.
Couldn't this cause problems for NFS? The same inode no longer has a
stable inode number across reboots. Basing on dentry location can also
be an information leak and cause problems on 64bit machines with old
userspace.
We could keep the original approach and use a static counter otherwise.
Something roughly like this:
static ino_t cramfs_get_ino(struct super_block *sb,
struct cramfs_inode *cramfs_inode)
{
static ino_t counter;
struct inode *inode;
if (cramfs_inode->offset && cramfs_inode->size)
return cramfs_inode->offset << 2;
for (;;) {
counter++;
if (!counter & 3)
counter++; /* skip numbers that could be offsets */
inode = cramfs_iget(sb, counter);
if (!inode)
return counter; /* free to use */
iput(inode);
}
}
> This lets us change and unlink files in a later patch
> without changing all other files that contain the same
> data, and it fixes a user-visible bug with 'cp -a'
> trying to hardlink empty directories when copying from
> a cramfs source.
>
> A slight disadvantage is that identical files no longer
> share a common page cache, so the data has to be read
> from disk for each file individually.
That seems to be solved with above approach as well.
Jörn
--
You can take my soul, but not my lack of enthusiasm.
-- Wally
next prev parent reply other threads:[~2008-06-01 16:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20080531152013.031903990@arndb.de>
2008-05-31 15:20 ` [RFC 1/7] cramfs: allow remount rw arnd
2008-05-31 15:20 ` [RFC 2/7] cramfs: create unique inode numbers arnd
2008-06-01 16:50 ` Jörn Engel [this message]
2008-06-01 21:24 ` Arnd Bergmann
2008-06-02 5:42 ` Jörn Engel
2008-05-31 15:20 ` [RFC 3/7] cramfs: allow unlinking of files arnd
2008-06-01 16:54 ` Jörn Engel
2008-06-01 21:28 ` Arnd Bergmann
2008-05-31 15:20 ` [RFC 4/7] cramfs: allow rmdir arnd
2008-05-31 15:20 ` [RFC 5/7] cramfs: allow writing to existing files arnd
2008-05-31 15:20 ` [RFC 6/7] cramfs: read directory entries from dcache arnd
2008-05-31 15:20 ` [RFC 7/7] cramfs: add missing inode operations arnd
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=20080601165048.GC13094@logfs.org \
--to=joern@logfs.org \
--cc=arnd@arndb.de \
--cc=hch@lst.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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