Messages in this thread | | | Date | Thu, 10 Nov 2005 14:04:19 +0000 | From | Al Viro <> | Subject | Re: [PATCH 1/2] handling 64bit values for st_ino] |
| |
On Thu, Nov 10, 2005 at 08:52:15AM -0500, Peter Staubach wrote: > Two different sized types to describe inode numbers, different paths, etc. > Having two of something, when just one would suffice, is usually more > complicated.
_What_ different paths? And what "two of something"?
The only requirement for fs that want to report wider st_ino is to put the right value into kstat->ino in their ->getattr().
And there's already a plenty of filesystems using iget5() et.al. for icache lookups - this isn't adding anything new.
As far as 64bit ino_t is concerned - no, thanks. We'd need to walk through all existing fs code and audit existing uses of ino_t. Which is far more of support burden.
And then there's an issue of overhead on normal icache lookups for nearly all existing filesystems; ones that do wider lookup keys are *already* using iget5(), BTW. So you'll simply punish all users of iget(). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |