Re: [CFT] ZFS ACL and rrwlock speedup

From: Scott Ullrich <sullrich_at_gmail.com>
Date: Fri, 27 Aug 2010 16:06:33 -0400
2010/8/24 Martin Matuska <mm_at_freebsd.org>:
> Dear FreeBSD community,
>
> in my last CFT I presented a patch that improves ZFS write speed. There
> have been easily portable improvements on the read side in OpenSolaris,
> too. Of course, the improvement here is by far not that dramatic as in
> the zfs_metaslab.patch, but OpenSolaris developers claim this also
> improves the speed of stat() calls.
>
> I would like to Call For Testing for the following patch (9-CURRENT):
> http://people.freebsd.org/~mm/patches/zfs/zfs_abe_stat_rrwlock.patch
>
> This patch adds the following:
> - better ACL caching and speedup of the ACL permission checks
> - lowered mutex contention in the read/writer lock (rrwlock)
> - several bugfixes
>
> This patch does not interfere with the zfs_metaslab.patch
>
> To apply the patch against 8-STABLE, you need to apply the v15 update first:
> http://people.freebsd.org/~mm/patches/zfs/v15/stable-8-v15.patch
>
> The patch imports the following OpenSolaris onnv revisions:
> 9749 (without zlook), 9866, 9981, 10143, 10232, 10295, 10250, 10269
>
> And covers the following OpenSolaris Bug IDs:
> 6802734 Support for Access Based Enumeration (not used on FreeBSD)
> 6844861 inconsistent xattr readdir behavior with too-small buffer
> 6848431 zfs with rstchown=0 or file_chown_self privilege allows user to
> "take" ownership
> 6775100 stat() performance on files on zfs should be improved
> 6827779 rrwlock is overly protective of its counters
> 6857433 memory leaks found at: zfs_acl_alloc/zfs_acl_node_alloc
> 6860318 truncate() on zfsroot succeeds when file has a component of its
> path set without access permission
> 6865875 zfs sometimes incorrectly giving search access to a dir
> 6870564 panic in zfs_getsecattr
> 6867395 zpool_upgrade_007_pos testcase panic'd with BAD TRAP: type=e
> (#pf Page fault)
> 6868276 zfs_rezget() can be hazardous when znode has a cached ACL

So far so good on this patch as well.  Running it for a good 3 days
with 4TB and it is nice and fast (220MB/sec for 1.5 TB drives).

Scott
Received on Fri Aug 27 2010 - 18:31:56 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:06 UTC