Re: CVS commit: src/external/cddl/osnet/dist/uts/common/fs/zfs

2012-10-15 Thread Taylor R Campbell
   Module Name:src
   Committed By:   riastradh   
   Date:   Mon Oct 15 14:03:06 UTC 2012

   Modified Files:
   src/external/cddl/osnet/dist/uts/common/fs/zfs: zfs_dir.c
   src/external/cddl/osnet/dist/uts/common/fs/zfs/sys: zfs_znode.h

   Log Message:
   Do reference counting for zfs range lock waiters.

Pasted the wrong commit message here.  Fixed now with `cvs admin'.
Sorry for the confusion!


Re: CVS commit: [tls-maxphys] src/sys/ufs/ufs

2012-10-15 Thread Manuel Bouyer
On Sun, Oct 14, 2012 at 02:33:32PM +, Thor Lancelot Simon wrote:
 Module Name:  src
 Committed By: tls
 Date: Sun Oct 14 14:33:32 UTC 2012
 
 Modified Files:
   src/sys/ufs/ufs [tls-maxphys]: ufs_readwrite.c
 
 Log Message:
 In the FFS writebehind code (ufs_readwrite.c:WRITE()), use division
 and multiplication instead of shifts, to accomodate devices with
 MAXPHYS that is a multiple of the page size, but not a power of 2.
 
 MegaRAID neatly writes out 192k chunks now.
 
 An open question: is is really a good idea to always writebehind
 at the largest size supported by the device?  Likely not, as this
 could have a major impact on I/O fairness.  OS X and Solaris both
 seem to limit transfers to 128k likely for this reason (the same
 problem exists with the readahead code but since it is adaptive,
 it will not *always* do huge transfers).
 
 However, simply imposing a smallish limit like 128k here seems
 like a bad idea because then we cannot accomodate greedy devices
 like RAID, for which you want something like 128k * number of
 data components.  Hmm.

I wonder if we could reuse bits from the read-ahead code for write-behind ?

Maybe this could allow to move the write-behind code out of ufs_readwrite.c
to ubc (maybe ubc_uiomove()) ?

-- 
Manuel Bouyer bou...@antioche.eu.org
 NetBSD: 26 ans d'experience feront toujours la difference
--