> On 1. Apr 2017, at 20:41, Taylor R Campbell
> wrote:
>
> Currently:
>
> - For VOP_INACTIVE, vnode lock is held on entry and released on exit.
> - For VOP_RECLAIM, vnode lock is not held on entry.
>
> I would like to change this so that:
>
> - For VOP_INACTIVE, vnode lock is held on entry a
> On 1. Apr 2017, at 23:03, Taylor R Campbell
> wrote:
>
>> Date: Thu, 30 Mar 2017 11:21:41 +0200
>> From: "J. Hannken-Illjes"
>>
>> Plan is to untangle the mountlist processing from vfs_busy() / vfs_unbusy()
>> and add an iterator for the mountlist:
>
> Generally seems like a good idea to m
> When SCSI tagged queueing is used properly, it is not necessary to set WCE
> to get good write performance
I will be eager to test this in Real Life once NetBSD ``uses tagged queueing
properly''.
> and doing so is in fact harmful, since it allows the drive to return
> ORDERED commands as comp
> Now, it might be the case that the on-media integrity is not the
> primary goal. Then flush is only a write barrier, not integrity
> measure. In that case yes, ORDERED does keep the semantics (e.g.
> earlier journal writes are written before later journal writes).
So either I'm completely wrong o
> Date: Sun, 2 Apr 2017 10:47:42 +0200
> From: "J. Hannken-Illjes"
>
> > On 1. Apr 2017, at 20:41, Taylor R Campbell
> > wrote:
> > VOP_RECLAIM then *destroys* the lock, so we don't have to say whether
> > it is held or released on exit. This requires a one-line change to
> > vfs_vnode.c, and
> Date: Sun, 2 Apr 2017 11:09:49 +0200
> From: "J. Hannken-Illjes"
>
> > On 1. Apr 2017, at 23:03, Taylor R Campbell
> > wrote:
> >
> > Any particular reason to use a pointer-to-opaque-pointer here instead
> > of a caller-allocated struct mountlist_iterator object?
>
> Just to make it opaque
> On 2. Apr 2017, at 16:05, Taylor R Campbell
> wrote:
>
>> Date: Sun, 2 Apr 2017 10:47:42 +0200
>> From: "J. Hannken-Illjes"
>>
>>> On 1. Apr 2017, at 20:41, Taylor R Campbell
>>> wrote:
>>> VOP_RECLAIM then *destroys* the lock, so we don't have to say whether
>>> it is held or released on
> On 2. Apr 2017, at 16:34, Taylor R Campbell
> wrote:
>
>> Date: Sun, 2 Apr 2017 11:09:49 +0200
>> From: "J. Hannken-Illjes"
>>
>>> On 1. Apr 2017, at 23:03, Taylor R Campbell
>>> wrote:
>>>
>>> Any particular reason to use a pointer-to-opaque-pointer here instead
>>> of a caller-allocate
t...@panix.com (Thor Lancelot Simon) writes:
>> We have tons of parallelism for writing and a small amount for reading.
>Unless you've done even more than I noticed, allocation in the filesystems
>is going to be a bottleneck -- concurrent access not having been foremost
>in anyone's mind when FFS
On Sat, Apr 01, 2017 at 09:26:50AM +, Michael van Elst wrote:
>
> >Setting WCE on SCSI drives is simply a bad idea. It is
> >not necessary for performance and creates data integrity
> >isues.
>
> I don't know details about data integrity issues although
> I'm sure there are some. But unfortu
> Date: Sun, 2 Apr 2017 16:34:20 +0200
> From: "J. Hannken-Illjes"
>
> Looks like your proposal needs some clarification regarding "vnode lock"
> and "the lock".
>
> We have two vnode related locks:
>
> - the "vnode lock", located as field "vi_lock" in "struct vnode_impl"
> used by genfs_*loc
> On 2. Apr 2017, at 18:19, Taylor R Campbell
> wrote:
>
>> Date: Sun, 2 Apr 2017 16:34:20 +0200
>> From: "J. Hannken-Illjes"
>>
>> Looks like your proposal needs some clarification regarding "vnode lock"
>> and "the lock".
>>
>> We have two vnode related locks:
>>
>> - the "vnode lock", lo
On Sat, Feb 25, 2017 at 10:35:27PM +0100, Joerg Sonnenberger wrote:
> (2) A hack for allow mprotect to switch between W and X, but still
> honoring W^X. This is a hack and needs to be carefully rethought,
> since I believe the way pax is currently implemented is wrong. Consider
> it a PoC.
Attache
Hi Taylor,
I have a couple of questions about the format of my proposal as well as
declarations with respect to my schedule in the summer, just so we're on
the same page.
*Firstly, the questions about my rough draft.*
> >1. The *free* page queues, serialized by uvm_fpageqlock, are handled
> >
14 matches
Mail list logo
