On Mar 3, 2014, at 3:28 PM, Taylor R Campbell
wrote:
> Date: Mon, 3 Mar 2014 11:11:04 +0100
> From: "J. Hannken-Illjes"
>
> Add an interface to iterate over a vnode list:
>
> void vfs_vnode_iterator_init(struct mount *mp, void **marker)
>
On Mar 3, 2014, at 4:11 PM, Taylor R Campbell
wrote:
> Date: Mon, 3 Mar 2014 15:55:16 +0100
> From: "J. Hannken-Illjes"
>
> On Mar 3, 2014, at 3:28 PM, Taylor R Campbell
> wrote:
>
>> /* mount.h */
>> struct vnode_iterator; /* opaque */
&g
On Mar 3, 2014, at 4:25 PM, Taylor R Campbell
wrote:
> Date: Mon, 3 Mar 2014 16:19:40 +0100
> From: "J. Hannken-Illjes"
>
> On Mar 3, 2014, at 4:11 PM, Taylor R Campbell
> wrote:
>
>> That is exactly what I was going for, except with a typed po
.
Diff is at http://www.netbsd.org/~hannken/vnode-pass5-1.diff
Comments or objections anyone?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
On Mar 21, 2014, at 3:07 PM, Taylor R Campbell
wrote:
> Date: Fri, 21 Mar 2014 11:10:54 +0100
> From: "J. Hannken-Illjes"
>
> The vnode flags VI_CLEAN and VI_XLOCK are used in file systems to
> check for reclaimed or reclaiming but still active vnodes, so
}
> + mutex_exit(vp->v_interlock);
> + vn_lock(vp, LK_EXCLUSIVE | LK_RETRY);
This will now be:
if (vdead_check(vp, VDEAD_NOWAIT) == 0 && vp->v_specnode != NULL)
There is no need to unlock/relock the vnode here.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
://www.netbsd.org/~hannken/vnode-pass6-1.diff
Comments or objections anyone?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
On 06 Apr 2014, at 21:12, David Holland wrote:
> On Sun, Apr 06, 2014 at 12:14:24PM +0200, J. Hannken-Illjes wrote:
>> Currently all file systems have to implement their own cache of
>> vnode / fs node pairs. Most file systems use a copy and pasted
>> version of ufs_i
On 07 Apr 2014, at 03:22, Taylor R Campbell
wrote:
> Date: Sun, 6 Apr 2014 12:14:24 +0200
> From: "J. Hannken-Illjes"
>
> Currently all file systems have to implement their own cache of
> vnode / fs node pairs. Most file systems use a copy and pasted
On 07 Apr 2014, at 17:44, Mindaugas Rasiukevicius wrote:
> "J. Hannken-Illjes" wrote:
>> Currently all file systems have to implement their own cache of
>> vnode / fs node pairs. Most file systems use a copy and pasted
>> version of ufs_ihash.
>>
>>
On 07 Apr 2014, at 18:02, Taylor R Campbell
wrote:
> Date: Mon, 7 Apr 2014 15:51:00 +0200
> From: "J. Hannken-Illjes"
>
> On 07 Apr 2014, at 03:22, Taylor R Campbell
> wrote:
>
>> Is the plan to nix getnewvnode and ungetnewvnode? It would be good to
On 07 Apr 2014, at 18:38, Taylor R Campbell
wrote:
> Date: Mon, 7 Apr 2014 18:32:02 +0200
> From: "J. Hannken-Illjes"
>
> On 07 Apr 2014, at 18:02, Taylor R Campbell
> wrote:
>
>> In that case, could you set the VI_CHANGING bit in vp, rather th
On 07 Apr 2014, at 19:28, Chuck Silvers wrote:
> On Sun, Apr 06, 2014 at 12:14:24PM +0200, J. Hannken-Illjes wrote:
>> Currently all file systems have to implement their own cache of
>> vnode / fs node pairs. Most file systems use a copy and pasted
>> version of ufs_i
On 07 Apr 2014, at 18:02, Taylor R Campbell
wrote:
> Date: Mon, 7 Apr 2014 15:51:00 +0200
> From: "J. Hannken-Illjes"
>
> On 07 Apr 2014, at 03:22, Taylor R Campbell
> wrote:
>
>> Is the plan to nix getnewvnode and ungetnewvnode? It would be good to
On 09 Apr 2014, at 15:57, Taylor R Campbell
wrote:
> Date: Wed, 9 Apr 2014 11:10:37 +0200
> From: "J. Hannken-Illjes"
>
> There is no need to do this VI_CHANGING etc. here. Primary goal of
> the vnode cache is to always initialise vnode / fs node pairs befor
On 09 Apr 2014, at 19:09, Chuck Silvers wrote:
> On Tue, Apr 08, 2014 at 11:23:11AM +0200, J. Hannken-Illjes wrote:
>>
>> On 07 Apr 2014, at 19:28, Chuck Silvers wrote:
>>
>>> On Sun, Apr 06, 2014 at 12:14:24PM +0200, J. Hannken-Illjes wrote:
>>>> Cu
On 09 Apr 2014, at 19:09, Chuck Silvers wrote:
> On Tue, Apr 08, 2014 at 11:23:11AM +0200, J. Hannken-Illjes wrote:
>>
>> On 07 Apr 2014, at 19:28, Chuck Silvers wrote:
>>
>>> On Sun, Apr 06, 2014 at 12:14:24PM +0200, J. Hannken-Illjes wrote:
>>>> Cu
On 07 Apr 2014, at 19:28, Chuck Silvers wrote:
> On Sun, Apr 06, 2014 at 12:14:24PM +0200, J. Hannken-Illjes wrote:
>> Currently all file systems have to implement their own cache of
>> vnode / fs node pairs. Most file systems use a copy and pasted
>> version of ufs_i
On 15 Apr 2014, at 18:11, Taylor R Campbell
wrote:
> Date: Mon, 14 Apr 2014 15:58:28 +0200
> From: "J. Hannken-Illjes"
>
> Also replaced the cv_wait/cv_broadcast with kpause as insert collisions
> are very rare and moved the common vnode initialisation to vn
ODE.
I prefer a fs operation over a vnode operation to initialise a
vnode. Using a vnode operation we had to either pass the vnode
operations vector to vache_get() which is ugly or we had to set
it from "*mp->mnt_op->vfs_opv_descs[0]->opv_desc_vector_p" before
calling VOP_LOAD()
e is to have one table for all vnodes.
Second, regarding space this even gets smaller. A hash table allocates
next_power_of_two(desiredvnodes) list heads so every hash table accounts
for ~1.5 pointers per vnode.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
same node.
Having per-mount tables would not change anything here.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
f (vio->vnd_flags & VNDIOF_HASGEOM) {
>
>memcpy(&vnd->sc_geom, &vio->vnd_geom,
>sizeof(vio->vnd_geom));
>
> How can VNDIOF_HASGEOM ever be set?
With from vnconfig(8)?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
On 29 Apr 2014, at 18:23, Patrick Welche wrote:
> On Tue, Apr 29, 2014 at 04:44:52PM +0100, Patrick Welche wrote:
>> On Tue, Apr 29, 2014 at 04:08:02PM +0200, J. Hannken-Illjes wrote:
>>> On 29 Apr 2014, at 15:19, Patrick Welche wrote:
>>>
>>>
>>>
On 28 Apr 2014, at 10:56, J. Hannken-Illjes wrote:
>
> Could we finally agree on this interface:
>
> vcache_get(mp, key, key_len, vpp) to lookup and possibly load a vnode.
> vcache_lookup(mp, key, key_len, vpp) to lookup a vnode.
> vcache_remove(mp, key, key_len) to remov
On 01 May 2014, at 18:06, David Holland wrote:
> On Mon, Apr 28, 2014 at 10:56:44AM +0200, J. Hannken-Illjes wrote:
>>> Wading into this after the fact, I see the following points:
>>>
>>> - Duplicating the getnewvnode logic is definitely bad; we have enoug
On 01 May 2014, at 20:02, David Holland wrote:
> On Thu, May 01, 2014 at 06:49:41PM +0200, J. Hannken-Illjes wrote:
>>> ok, in that case I think the only issue with the patch I looked at
>>> Sunday (was it that long ago already?) is that it does duplicate the
>>>
mand) in more detail.
Will "systat vmstat 1" show anything during the pause?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
On 22 May 2014, at 13:27, Christos Zoulas wrote:
> In article <0e8bfcfc-c4cd-4ce3-8bac-22eb8ebd3...@eis.cs.tu-bs.de>,
> J. Hannken-Illjes wrote:
>> On 22 May 2014, at 03:15, Christos Zoulas wrote:
>
>>> - start a build
>>> - hold a key down at the
On 22 May 2014, at 18:47, Christos Zoulas wrote:
> In article <2b9bf96f-5db2-4b91-8fd0-a01f0f455...@eis.cs.tu-bs.de>,
> J. Hannken-Illjes wrote:
>> On 22 May 2014, at 13:27, Christos Zoulas wrote:
>>
>>> In article <0e8bfcfc-c4cd-4ce3-8bac-22eb8ebd3...@eis
On 23 May 2014, at 01:50, Christos Zoulas wrote:
> In article ,
> J. Hannken-Illjes wrote:
>>
>> While I'm interested in the results, this change is wrong. As long as
>> we have forced unmount and revoke it is not safe to access an inode
>> without locking
On 23 May 2014, at 13:42, Christos Zoulas wrote:
> In article <09108bb8-536e-48e2-906e-cdf6e0962...@eis.cs.tu-bs.de>,
> J. Hannken-Illjes wrote:
>>
>> Does the attached diff help?
>
> No, I don't think it does.
Christos, please try it. Of the locks involve
On 22 May 2014, at 13:27, Christos Zoulas wrote:
> In article <0e8bfcfc-c4cd-4ce3-8bac-22eb8ebd3...@eis.cs.tu-bs.de>,
> J. Hannken-Illjes wrote:
>> On 22 May 2014, at 03:15, Christos Zoulas wrote:
>>
>>> In article ,
>>> Christos Zoulas wrote:
&g
On 23 May 2014, at 20:15, Christos Zoulas wrote:
> In article ,
> J. Hannken-Illjes wrote:
>>
>> Ok, so I tried a kernel with DEBUG+LOCKDEBUG and get the same problems
>> you describe: every 10 to 20 seconds I get hickups of 1 to 2 seconds.
>>
>> Christos,
On 24 May 2014, at 19:32, Christos Zoulas wrote:
> In article <69ce1ce4-6c54-4e17-802d-679a6a165...@eis.cs.tu-bs.de>,
> J. Hannken-Illjes wrote:
>>
>> Ok, see me convinced.
>
> Great :-)
>
>> First, selector and context should be passed to vfs_vnode
On 24 May 2014, at 20:16, Christos Zoulas wrote:
> In article ,
> J. Hannken-Illjes wrote:
>>
>> Why didn't you commit it then?
>
> I just did.
I mean this: "selector and context should be passed to
vfs_vnode_iterator_init as they are invariant."
C
On 25 May 2014, at 12:22, Christos Zoulas wrote:
> In article ,
> J. Hannken-Illjes wrote:
>> On 24 May 2014, at 20:16, Christos Zoulas wrote:
>>
>>> In article ,
>>> J. Hannken-Illjes wrote:
>>>>
>>>> Why didn't you commi
where my test causes havoc.
>
> So this could be a DoS attack path.
The upcoming conversion to vcache should make it easier to deal with
these problems. I will add some priority to the conversion of cd9660.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
just
released the buffer or will be used in the near future when the
directory gets traversed during lookup.
Comments or objections anyone?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
cd9660.diff
Description: Binary data
om all key arguments.
Comments or objections anyone?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
vcache-rekey.diff
Description: Binary data
On 25 Jun 2014, at 11:46, Taylor R Campbell
wrote:
> Date: Wed, 25 Jun 2014 11:24:16 +0200
> From: "J. Hannken-Illjes"
>
> The attached diff adds a new vcache operation
>
> void
> vcache_rekey(struct mount *mp, void *old_key, size_t ol
ne key with
> another requires unconsting something isn't right. The cache should
> only be reading the key, and supplying a new one doesn't change that...
How could we ATOMICALLY change a key when it is read-only aka. const?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
id *old_key, size_t old_key_len,
const void *new_key, size_t new_key_len)
to finish the key change. It will remove the old cache node and setup
and unlock the new cache node.
Comments, suggestions or objections?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
vcache.diff
Description: Binary data
18 06:00 UTC' '2012-09-18 09:00 UTC'.
Someone should redo this test as this interval is the import of the
compiler (GCC 4.5.3 -> 4.5.4) and I had to rebuild tools. I cant
believe this to be a compiler problem.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (G
On 24 Aug 2014, at 18:57, J. Hannken-Illjes wrote:
> I tried to bisect and got an increase in time from ~15 secs to ~24 secs
> between the time stamps '2012-09-18 06:00 UTC' '2012-09-18 09:00 UTC'.
>
> Someone should redo this test as this interval is the imp
On 25 Aug 2014, at 17:39, Taylor R Campbell wrote:
> Date: Mon, 25 Aug 2014 15:55:53 +0200
> From: "J. Hannken-Illjes"
>
> GCC 4.5.4 disabled builtin memcmp as x86 has no cmpmemsi pattern.
>
> See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052, Comment
On 25 Aug 2014, at 15:55, J. Hannken-Illjes wrote:
> On 24 Aug 2014, at 18:57, J. Hannken-Illjes wrote:
>
>
>
>> I tried to bisect and got an increase in time from ~15 secs to ~24 secs
>> between the time stamps '2012-09-18 06:00 UTC' '2012-09-18 09:0
> return VOP_PUTPAGES(vp, off, off + len,
> PGO_CLEANIT|PGO_SYNCIO);
> }
>
> --
> Emmanuel Dreyfus
> m...@netbsd.org
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
On 02 Oct 2014, at 06:45, Emmanuel Dreyfus wrote:
> J. Hannken-Illjes wrote:
>
>> genfs_gop_write calls genfs_do_io which does "error = biowait(mbp);"
>> near the end. This will catch errors from VOP_STRATEGY.
>
> I run the code below but VOP_PUTPAGES never
On 02 Oct 2014, at 17:23, Emmanuel Dreyfus wrote:
> On Thu, Oct 02, 2014 at 12:02:39PM +0200, J. Hannken-Illjes wrote:
>> GOP_ALLOC() gets called from VOP_GETPAGES() for missing pages. Here you
>> run VOP_PUTPAGES() on a range known to be unmapped so it becomes a NOP.
>>
On 02 Oct 2014, at 19:09, Emmanuel Dreyfus wrote:
> J. Hannken-Illjes wrote:
>
>> Please describe "cached write operation" in terms of vnode operations.
>
> A write on a mount that uses page cache, without direct I/O.
>
>> Which vnode operation final
rotocol version number.
If you want to make UBC work with PUFFS fsx may help. Last time
I tried it failed badly on a rump_ffs mount. You may find it here:
http://www.netbsd.org/~hannken/fsx.tgz
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
stem blocksize */
>
> Tested on NetBSD-current: no longer crashes.
>
> Ok/Comments?
Looks ok.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
de
as sparse until it is sure not to have holes, which is when we get
va_bytes != VNOVAL && vp->v_size == rvap->va_bytes.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
t; during the operation?
- Increment PUFFSVERSION.
- You should recover the error in puffs_vnop_close() too.
- Are you sure pn_sizemtx is still needed? VOP_GETATTR() works on
locked vnodes since 2011-10-30.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
On 26 Oct 2014, at 08:46, Emmanuel Dreyfus wrote:
> J. Hannken-Illjes wrote:
>
>> - Increment PUFFSVERSION.
>
> When is it really required? Without incrementing it, a newer kernel
> works with an older libpuffs, but if I increase it I get an error about
> version mism
On 26 Oct 2014, at 17:55, Emmanuel Dreyfus wrote:
> J. Hannken-Illjes wrote:
>
>> What happens when libpuffs receives an unknown message (fallocate in
>> this case)?
>
> The filesystem using libpuffs tells the kernel what operations should be
> sent to userland whe
On 26 Oct 2014, at 19:13, Emmanuel Dreyfus wrote:
> J. Hannken-Illjes wrote:
>
>> Since it was last incremented at Rev. 1.72 many messages got additional
>> fields so the version should be incremented independent of your change.
>
> What messages are you referri
On 28 Oct 2014, at 14:37, Emmanuel Dreyfus wrote:
> On Sun, Oct 26, 2014 at 09:21:13AM +0100, J. Hannken-Illjes wrote:
>> - You should recover the error in puffs_vnop_close() too.
>
> Should I? puffs_vnop_close() does not cause VOP_STRATEGY to be
> called, it only sen
On 28 Oct 2014, at 15:43, Emmanuel Dreyfus wrote:
> On Tue, Oct 28, 2014 at 02:52:36PM +0100, J. Hannken-Illjes wrote:
>> NFS allows them and therefore VOP_CLOSE is the last chance to report
>> write errors back to the application.
>
> The situation is a bit different:
T(0)" with 0 being the vnode address.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
#x27;t work even with root being a directory because the namei() call
would hang in VOP_LOOKUP(). Does it work these days?
> 2) Desfine a new MNT_RAW mount flag. If umount(8) is called with -R,
> pass that flag to unmount(8), and in sys_unmount(), do not use FOLLOW if
> MNT_RAW is set.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
* Open is in progress, but not complete, must wait
> + * for it to complete.
> + */
> + cv_wait(&specopenclose_cv, &device_lock);
> + }
> if (sn->sn_opencnt != 0) {
> sd->sd_opencnt -= (sn->sn_opencnt - 1);
> sn->sn_opencnt = 1;
Will this work if we revoke a device whose cdev_open() blocks,
a TTY waiting for carrier for example?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
o me, didn't test it either.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
s read with the
same size).
> I don't understand what the BC_INVAL flag means, and its definition
> in sys/buf.h is not very enlightening:
>
> #define BC_INVAL0x2000 /* Does not contain valid info.
> */
>
> Which branch do I keep?
Both.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
ialised
and has link count zero.
A diff showing the implementation is here:
http://www.netbsd.org/~hannken/vnode-pass7-1a.diff
and a diff showing its usage for ffs is here:
http://www.netbsd.org/~hannken/vnode-pass7-1b.diff
Comments or objections anyone?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
if (i++ > 1)
kpause("psrlz", false, 1, NULL);
mutex_spin_enter(&psz_lock);
} while (!kcpuset_iszero(psz->psz_target));
to become faster in the usual "two activity switches" case.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
ooks ok to me.
Please take a look at breadn() too.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
, no further copy-on-write and reading
gives ENXIO (Device not configured).
The snapshot device stays configured.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
VFS_SYNC as appropriate.
- use an API for mount points similiar to the API for vnodes.
Diff at http://www.netbsd.org/~hannken/rm-miscfs-syncfs-1.diff
Comments or objections anyone?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
On 01 May 2015, at 14:16, Christos Zoulas wrote:
> In article ,
> J. Hannken-Illjes wrote:
>> Our miscfs/syncfs originating from the softdep import is a pseudo
>> file system with one VOP. Its vnodes get used as a kind of marker
>> on the syncer worklist so the syncer m
On 01 May 2015, at 20:02, David Holland wrote:
> On Fri, May 01, 2015 at 10:17:05AM +0200, J. Hannken-Illjes wrote:
>> Our miscfs/syncfs originating from the softdep import is a pseudo
>> file system with one VOP. Its vnodes get used as a kind of marker
>> on the syncer w
to sc_flags etc. are protected by mutex.
- locking is no longer interruptible (no PCATCH / cv_wait_sig), not
sure if this is a problem.
- keep the first blank line for functions without locals.
- do the white space change with a separate commit.
Otherwise looks like a good starting point.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
nction nfs_node.c:nfs_gop_write(). Falling back to genfs_gop_write()
ignores nfs timeouts.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
me to all names in the
directory so far leading to 0.5*n*(n-1) calls to memcmp.
And our memcmp is slw ...
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
On 18 Aug 2015, at 15:06, Joerg Sonnenberger wrote:
> On Tue, Aug 18, 2015 at 01:06:02PM +0200, J. Hannken-Illjes wrote:
>> And our memcmp is slw ...
>
> Do you have any thing substancial to justify this?
This topic has already been discussed last year, see
http://mail-i
e syssrc
> tarball, this looks wrong. It also immediately causes the suspicion
> that the list isn't in fact protected at all.
This file (fs/nfs/client/nfs_clvnops.c) is part of a second (dead) nfs
implementation from FreeBSD. It is not part of any kernel.
Our nfs lives in sy
^
Looks like your sources got mixed from 7.0 and -current.
On 7.0 file usr.sbin/makefs/ffs/buf.h is revision 1.9 and has:
int bread(struct vnode *, daddr_t, int, struct kauth_cred *, int,
struct buf **);
while on -current its revision is 1.10 and has:
int bread(struct vnode *, daddr_t, int, int, struct buf **);
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
pts to write to the locked part
the lock (+) would return EAGAIN ...
Wouldn't it be better to put the mandatory locking at the file->vnode
level, operations vn_read() and vn_write()?
Could you explain the proposed semantics in detail?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
es make the claimed mutual exclusion between lock
and mmap similarly unreliable.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
if the flags
(the last argument) contain "F_POSIX" and "struct file *" otherwise.
Fcntl(2) uses F_POSIX where flock(2) does not.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
Comments or objections anyone?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
> On 20 May 2016, at 18:31, Taylor R Campbell
> wrote:
>
> Date: Fri, 20 May 2016 16:38:22 +0200
> From: J. Hannken-Illjes
>
> 1) Objects vnode and vcache_node always exist together so it makes sense
> to merge them into one object. This can be done in tw
ce, but the
> close() routine is only called once. So every iteration leaves the refcount
> with a net increment of one.
>
> I cannot figure out why/how the open routine is called twice.
IIRC the device open() operation gets called on every open while
the device close() operation gets called on last close only.
See misfs/specfs/spec_vnops.c::spec_close().
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
sts, merge vrele_thread()
into vdrain_thread() and adapt vfs_drainvnodes().
Diffs are here: https://www.netbsd.org/~hannken/lrulist/
Comments or objections anyone?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
aiting for locked parent vnode from the rename
Do you have full backtrace?
Where is the syncer waiting for the parent?
Which file system?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
> On 11 Dec 2016, at 22:33, Nick Hudson wrote:
>
> On 12/11/16 21:05, J. Hannken-Illjes wrote:
>>> On 11 Dec 2016, at 21:01, David Holland wrote:
>>>
>>> On a low-memory machine Nick ran into the following deadlock:
>>>
>>> (a) rena
, but we're ostensibly working
> towards it.)
>
> Does anyone have any suggestions for a patch to address this problem
> without first rewriting the syncer? While the latter is probably a
> good idea, it's not entirely trivial to do and get right, making it
> e.g. a poor
a stable state and
free the vnode if this hold was the last reference to a reclaimed vnode.
3) Add some "v_usecount == 1" assertions.
Diffs are here: https://www.netbsd.org/~hannken/vget/
Comments or objections anyone?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Br
not
scale well to support it for all file systems.
Plan is to move fstrans_start()/fstrans_done() into vnode_if.c and
enable vfs_suspend() on all file systems.
Diffs are here: https://www.netbsd.org/~hannken/vnode_if/
Comments or objections anyone?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de
> On 19 Feb 2017, at 18:08, Christos Zoulas wrote:
>
> In article ,
> J. Hannken-Illjes wrote:
>>
>> Comments or objections anyone?
>
> Will that detect open for write file descriptors to removed files?
This is the job of vflush(). Since Rev. 1.46 of vfs_m
gress.
- struct mount *_mountlist_next(struct mount *)
a lockless variant to be used from DDB only.
Diffs are here: https://www.netbsd.org/~hannken/ml_iterator/
Comments or objections anyone?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
> On 30. Mar 2017, at 17:20, Christos Zoulas wrote:
>
> In article <534552fb-af29-4219-8390-7514a2665...@eis.cs.tu-bs.de>,
> J. Hannken-Illjes wrote:
>> Currently vfs_busy() / vfs_unbusy() get used to
>>
>> - Enter/leave a critical section against unmoun
: Functions that VOP_RECLAIM calls would be able to assert,
> rather than vaguely assume, exclusive ownership of the vnode lock.
> Currently various code paths, e.g. ffs_update, require exclusive
> access to the vnode in question, which can't be asserted right now
> because of the
> 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 mo
> 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
> 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 particul
> 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&qu
erator_destroy(iter);
Diffs are here: https://www.netbsd.org/~hannken/ml_iterator2/
Comments or objections anyone?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
101 - 200 of 253 matches
Mail list logo
