Re: [RFC][PATCH] ensure i_ino uniqueness in filesystems without permanent inode numbers (via lazy hashing)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff Layton wrote:
Here is a different approach to the problem of i_ino uniqueness. Again,
I'll refer to my original email and patch for a description of the problem...

With this patch, I'm taking the approach of only assigning out an i_ino
value when it's actually needed. This adds a lazy_getattr function. If
i_ino is 0, then this does an iunique and hashes the inode before doing
the actual getattr.


Actually, after having a closer look at this, I don't think this turns out to be feasible either. Some filesystems (including pipefs) want an i_ino value early on for generating the qstr passed to d_alloc.

Since they want the value so early, there would be little benefit in attempting to delay assigning an i_ino value. It might be a win for some filesystems, but ones like pipefs and sockfs wouldn't be able to use this scheme, and those are the ones we're primarily concerned with performance-wise.

I'm going to plan to clean up my IDR patch and resubmit it, as I think it's probably the best scheme we have that seems to actually fix the problem.

Unless someone else has a better idea... :-)

-- Jeff

-
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

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux