Date: Wed, 27 Mar 2013 22:40:16 -0700 From: mdf@FreeBSD.org To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: [RFC] use a shared lock for VOP_GETEXTATTR Message-ID: <CAMBSHm_Rbw=0-nA%2Bn5JoT68L_4%2BKvAZM-o%2BS%2B01TqFZKacjfgQ@mail.gmail.com> In-Reply-To: <20130328053205.GF3794@kib.kiev.ua> References: <CAMBSHm8Akz2-tUhjYm9%2BH3YTN31N8=OhGHX1ZpdV4-VixFQm%2BQ@mail.gmail.com> <CAMBSHm9VgD9Pcmiap3Cy1eW8GD9k06q%2BsCzaSJ%2B_wyA6ZFioTA@mail.gmail.com> <20130328053205.GF3794@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 27, 2013 at 10:32 PM, Konstantin Belousov <kostikbel@gmail.com> wrote: > On Wed, Mar 27, 2013 at 06:37:51PM -0700, mdf@FreeBSD.org wrote: >> VOP_GETEXTATTR is currently called with an exclusive lock, which seems >> like overkill for what is essentially a read operation. I had a look >> over the various in-tree filesystems and it didn't look like any of >> them will have a problem if a shared-mode lock is used for >> vop_getextattr. >> >> Does anyone know otherwise? Is someone using extended attributes >> regularly who can test this? > > I think this change should be fine. At least it seems to for UFS. > > What other filesystems did you audited ? I looked over zfs, pseudofs, unionfs, ffs/ufs. None seemed to have any asserts on the lock type nor anything that looked like it would try to modify anything. zfs, I think it was, even used VOP_ISLOCKED to get the lock type in one path (but I think that was after a lookup(), so it may have been on a different vnode). Cheers, matthew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAMBSHm_Rbw=0-nA%2Bn5JoT68L_4%2BKvAZM-o%2BS%2B01TqFZKacjfgQ>