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

2012-10-16 Thread Thor Lancelot Simon 
On Mon, Oct 15, 2012 at 04:24:54PM +0200, Manuel Bouyer wrote:
> 
> I wonder if we could reuse bits from the read-ahead code for write-behind ?

I'm not sure the read-ahead code is working properly.  When I read through
the filesystem with cat or dd bs=1024k, on a device (wd on ahcisata)
that can do 1M transfers, I see that most transfers are considerably
smaller.

What I'm more worried about is that it may _never_ be a good idea, in the
general case, to put 1M transfers on the bus, particularly single writes,
since they may delay things like log transactions in the disk's write
cache.  We might need a much safer I/O scheduler before we can safely do
this.  Or we might need to let the user tune it on a per-filesystem basis.

Thor

Re: CVS commit: src/share/man/man3

2012-10-16 Thread SAITOH Masanobu 
(2012/10/17 4:13), Alan Barrett wrote:
> On Tue, 16 Oct 2012, SAITOH Masanobu wrote:
>> Modified Files:
>> src/share/man/man3: bits.3
>>
>> Log Message:
>> Return value of __BIT() and __BITS() is not uint32_t but uint64_t.
> 
> No, they are uintmax_t.
> 
> uintmax_t happens to be the same as uint64_t on all present day NetBSD
> platforms, but a new platform with a larger uintmax_t could appear one
> day.
> 
> --apb (Alan Barrett)

 Commited again.

 Thanks.

-- 
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/share/man/man3

2012-10-16 Thread Alan Barrett 

On Tue, 16 Oct 2012, SAITOH Masanobu wrote:

Modified Files:
src/share/man/man3: bits.3

Log Message:
Return value of __BIT() and __BITS() is not uint32_t but uint64_t.


No, they are uintmax_t.

uintmax_t happens to be the same as uint64_t on all present day NetBSD
platforms, but a new platform with a larger uintmax_t could appear one
day.

--apb (Alan Barrett)

Re: CVS commit: src/share/man/man3

2012-10-16 Thread Iain Hibbert 
On Tue, 16 Oct 2012, SAITOH Masanobu wrote:

> Module Name:  src
> Committed By: msaitoh
> Date: Tue Oct 16 17:39:35 UTC 2012
>
> Modified Files:
>   src/share/man/man3: bits.3
>
> Log Message:
> Return value of __BIT() and __BITS() is not uint32_t but uint64_t.

but surely, it is uintmax_t ??

regards,
iain

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

2012-10-16 Thread Taylor R Campbell 
   Date: Tue, 16 Oct 2012 09:47:32 +0200
   From: Alan Barrett 

   On Mon, 15 Oct 2012, Taylor R Campbell wrote:
   >@@ -796,7 +794,11 @@ zfs_link_destroy(zfs_dirlock_t *dl, znod
   >if (zp_is_dir && !zfs_dirempty(zp)) {   /* dir not empty */
   >mutex_exit(&zp->z_lock);
   >vn_vfsunlock(vp);
   >+#ifdef __NetBSD__  /* XXX Make our dumb tests happier...  */
   >+   return (ENOTEMPTY);
   >+#else
   >return (EEXIST);
   >+#endif
   >}

   I'd suggest using ifdef ENOTEMPTY instead of ifdef __NetBSD__ here.

Well, both NetBSD and Solaris have ENOTEMPTY -- it's in POSIX.  POSIX
says that rmdir and rename can return either ENOTEMPTY or EEXIST.
It's just that all our other file systems return ENOTEMPTY in this
case.

   (And the log message did not mention this change.)

Oops, sorry -- that change was supposed to go in a separate commit.
Should I change the commit message with `cvs admin', or revert the
change and fix the tests instead, or do something else altogether?

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

2012-10-16 Thread Alan Barrett 

On Mon, 15 Oct 2012, Taylor R Campbell wrote:

@@ -796,7 +794,11 @@ zfs_link_destroy(zfs_dirlock_t *dl, znod
if (zp_is_dir && !zfs_dirempty(zp)) {   /* dir not empty */
mutex_exit(&zp->z_lock);
vn_vfsunlock(vp);
+#ifdef __NetBSD__  /* XXX Make our dumb tests happier...  */
+   return (ENOTEMPTY);
+#else
return (EEXIST);
+#endif
}


I'd suggest using ifdef ENOTEMPTY instead of ifdef __NetBSD__ here.

(And the log message did not mention this change.)

--apb (Alan Barrett)