From mboxrd@z Thu Jan  1 00:00:00 1970
From: Chris Mason <chris.mason@oracle.com>
Subject: Re: .. anybody know of any filesystems that depend on the exact VFS
 'namehash' implementation?
Date: Thu, 1 Mar 2012 13:34:03 -0500
Message-ID: <20120301183403.GF5054@shiny>
References: <CA+55aFyv=OKUuAV6pqdmbHeUL7Motsh+n026nWqaT63aEgBjBQ@mail.gmail.com>
 <20120301165726.GF23916@ZenIV.linux.org.uk>
 <CA+55aFzxWifxyFSpQfuztmOiyBQpYfiM560DWXoooZ8j8p3fYw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: Al Viro <viro@zeniv.linux.org.uk>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Return-path: <linux-kernel-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <CA+55aFzxWifxyFSpQfuztmOiyBQpYfiM560DWXoooZ8j8p3fYw@mail.gmail.com>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: linux-fsdevel.vger.kernel.org

On Thu, Mar 01, 2012 at 09:14:13AM -0800, Linus Torvalds wrote:
> On Thu, Mar 1, 2012 at 8:57 AM, Al Viro <viro@zeniv.linux.org.uk> wro=
te:
> >
> > As long as full_name_hash() is still around, any such filesystem is=
 welcome
> > to use it for ->d_hash() and STFU.
>=20
> Well, I'd make full_name_hash() match the new hash model, so no, they
> couldn't use that. They'd have to actually implement the old hash, an=
d
> make it "their hash".
>=20
> Also note that the hash model would have to become dependent on confi=
g
> options: doing things a word at a time really only works well on
> architectures that have fast unaligned accesses, and even on those
> archtiectures it really doesn't work if you enable
> CONFIG_DEBUG_PAGE_ALLOC.
>=20
> > Note that there are places like this one (in btrfs_real_readdir())
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0q.name =3D name_ptr;
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0q.len =3D name_len;
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0q.hash =3D full_name=
_hash(q.name, q.len);
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tmp =3D d_lookup(fil=
p->f_dentry, &q);
> > and they _will_ need to be updated if we switch the default.
>=20
> I don't agree that it will need to be updated - I was planning on jus=
t
> updating full_name_hash() to always match. That part is easy and
> obvious.

Just to clarify, btrfs isn't putting the dcache hashes on disk.  The
code above is part of our optimization to preload some information we
find during readdir to reduce IO when the file is later opened.

On disk we're crc32c only.

-chris