On Sat, 31 May 2008 17:20:15 +0200, arnd@xxxxxxxx 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
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
