Changed "vfs_unmountall1()" to retrieve mounts in descending
generation order which has the additional benefit that we don't
need reverse traversals any more.
Diffs are here: https://www.netbsd.org/~hannken/ml_iterator2a/
I prefer this API, opinions?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
> On 6. Apr 2017, at 11:44, J. Hannken-Illjes wrote:
>
>>
>> On 5. Apr 2017, at 05:14, Chuck Silvers wrote:
>>
>> have you considered a callback-based interface where the loop
>> is inside the iteration API rather than in the caller?
>> the v
> On 9. Apr 2017, at 19:16, Taylor R Campbell
> wrote:
>
>> Date: Sun, 9 Apr 2017 18:47:25 +0200
>> From: "J. Hannken-Illjes"
>>
>>> On 6. Apr 2017, at 11:44, J. Hannken-Illjes wrote:
>>> Good hint. Prepared a partial implementation
renamed to vfs_rele(mp).
Operation vfs_trybusy(mp) gets added when needed.
Comments or objections?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
ems to
> describe this situation. Unfortunately, it seems that yamt never finished
> working on the problem. :(
Two questions:
- What is the size of your vnode cache (sysctl kern.maxvnodes)?
- Is the vdrain thread using CPU too?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
> On 17. May 2017, at 08:59, Paul Goyette wrote:
>
> On Wed, 17 May 2017, J. Hannken-Illjes wrote:
>
>>>> Chances are very high that you are hitting the free page lock contention
>>>> bug.
>>>
>>> Further observation:
>>>
to critical
> cases and try to avoid it for common cases.
>
> Thoughts?
>
> Joerg
>
Looks good to me, cannot test anything as I am on vacation.
Please commit and request pullup to -8.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
t inherited
> by the root vnode.
>
> http://www.netbsd.org/~rmind/tmpfs_mount_fix.diff
Very good catch, @martin could you try this diff on an autobuilder?
Looks like it speeds up tmpfs lookups by a factor of ~40 on -8.0.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
; * buffers from being queued.
> */
For me it triggers for mounted block devices only and I suppose the
vnode lock doesn't help here.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
sconfig "hangs" the dump is creating a snapshot. Creating
a snapshot (and suspending a file system) is serialized. Allowing
more than one file system suspension at a time will deadlock most
of the time.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
> On 12. Aug 2018, at 03:58, Emmanuel Dreyfus wrote:
>
> On Sat, Aug 11, 2018 at 10:33:04AM +0200, J. Hannken-Illjes wrote:
>> When fssconfig "hangs" the dump is creating a snapshot. Creating
>> a snapshot (and suspending a file system) is serialized. Allowi
> On 12. Aug 2018, at 10:07, Emmanuel Dreyfus wrote:
>
> On Sun, Aug 12, 2018 at 09:55:27AM +0200, J. Hannken-Illjes wrote:
>>> You mean you cannot at the same tme snapshot /mount0 on fss0 and
>>> /mount1 on fss1?
>>
>> Yes, you have to create the s
> On 13. Aug 2018, at 09:53, Emmanuel Dreyfus wrote:
>
> On Sun, Aug 12, 2018 at 10:16:48AM +0200, J. Hannken-Illjes wrote:
>> While creating a snapshot "/mount0" lookup "/mount0/file", it will block
>> as "/mount0" is suspended. The look
= FSS_ACTIVE;
mutex_exit(&sc->sc_lock);
return error;
Problem here is backwards compatibility. I have no idea what to
return for FSSIOCGET when the state is creating or destroying.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
ew buffer
and try to free a buffer on a currently suspending file system.
VFS_SYNC and VOP_BWRITE should be on different mounts here.
Do you have a crash dump?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
> On 14. Aug 2018, at 11:16, J. Hannken-Illjes wrote:
>
>
>> On 13. Aug 2018, at 19:25, Emmanuel Dreyfus wrote:
>>
>> On Mon, Aug 13, 2018 at 11:56:45AM +, Taylor R Campbell wrote:
>>> Unless I misunderstand fss(4), this is an abuse of mutex(9): nothin
> On 17. Aug 2018, at 04:46, Emmanuel Dreyfus wrote:
>
> On Thu, Aug 16, 2018 at 10:03:11AM +0200, J. Hannken-Illjes wrote:
>> Looks like a deadlock where we sync a file system, need a new buffer
>> and try to free a buffer on a currently suspending file system.
>>
> On 19. Aug 2018, at 20:30, David Holland wrote:
>
> On Thu, Aug 16, 2018 at 10:03:11AM +0200, J. Hannken-Illjes wrote:
>>> sleepq_block
>>> cv_wait
>>> fstrans_start
>>> VOP_BWRITE
>>> getnewbuf
>>> getblk
>>&
> On 20. Aug 2018, at 10:34, Emmanuel Dreyfus wrote:
>
> On Thu, Aug 16, 2018 at 12:18:34PM +0200, J. Hannken-Illjes wrote:
>> - 001_add_sc_state replaces the flags FSS_ACTIVE and FSS_ERROR with
>> a state field.
>>
>> - 002_extend_state adds states for co
> On 22. Aug 2018, at 08:50, Emmanuel Dreyfus wrote:
>
> On Mon, Aug 20, 2018 at 10:39:21AM +0200, J. Hannken-Illjes wrote:
>>> I applied that to NetBSD-8.0, and it seems to behave much better.
>> Good.
>
> Will you commit and request a pullup? The change is valu
> On 23. Aug 2018, at 11:59, J. Hannken-Illjes wrote:
>
>
>> On 22. Aug 2018, at 08:50, Emmanuel Dreyfus wrote:
>>
>> On Mon, Aug 20, 2018 at 10:39:21AM +0200, J. Hannken-Illjes wrote:
>>>> I applied that to NetBSD-8.0, and it seems to behave much b
*
> * No usable snapshots found.
> @@ -1847,8 +1850,9 @@
>si->si_snapblklist = xp->i_snapblklist;
>fscow_establish(mp, ffs_copyonwrite, devvp);
> si->si_gen++;
>mutex_exit(&si->si_lock);
> +#endif /* FFS_NO_SNAPSHOT */
> }
>
> /*
> * Disassociate snapshot files when unmounting.
>
>
>
> --
> Emmanuel Dreyfus
> http://hcpnet.free.fr/pubz
> m...@netbsd.org
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
> On 15. Sep 2018, at 17:06, Manuel Bouyer wrote:
>
> On Sat, Sep 15, 2018 at 04:34:41PM +0200, J. Hannken-Illjes wrote:
>> This will damage all persistent snapshots if you boot a kernel with
>> FFS_NO_SNAPSHOT
>> Pleas don't commit ...
>
> Can you
> On 18. Sep 2018, at 16:33, Manuel Bouyer wrote:
>
> On Tue, Sep 18, 2018 at 04:24:28PM +0200, J. Hannken-Illjes wrote:
>> There will be no copy-on-write to persistent snapshots so the snapshots
>> will contain garbage where the real file system writes data.
>
> H
> On 18. Sep 2018, at 16:39, J. Hannken-Illjes wrote:
>
>
>> On 18. Sep 2018, at 16:33, Manuel Bouyer wrote:
>>
>> On Tue, Sep 18, 2018 at 04:24:28PM +0200, J. Hannken-Illjes wrote:
>>> There will be no copy-on-write to persistent snapshots so the snapshot
> On 2. Oct 2018, at 12:23, Manuel Bouyer wrote:
>
> On Tue, Oct 02, 2018 at 12:11:49PM +0200, J. Hannken-Illjes wrote:
>>
>>> On 18. Sep 2018, at 16:39, J. Hannken-Illjes
>>> wrote:
>>>
>>>
>>>> On 18. Sep 2018, at 16:33,
t; INCORRECT BLOCK COUNT I=211471882 (11141696 should be 11142208)
> CORRECT? yes
Did the file system mount OK after fsck?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
Petr,
your kernel is elder than your ZFS module.
Please update to a current kernel and try again.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig
> On 28. May 2019, at 20:27, Petr Topiarz wrote:
>
> Hi Tech-kern,
>
> I run two machines with NetBSD amd64 w
e commit - looks like newer modules than kernel.
>> https://v4.freshbsd.org/commit/netbsd/src/IH8Jag0YCI3N6boB
Do we really expect module updates without updating kernel
to work?
If yes will do iot next time.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig
signature.asc
Description: Message signed with OpenPGP
ow could we test against the lowest address the kernel
may use?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig
signature.asc
Description: Message signed with OpenPGP
> On 1. Jul 2019, at 20:12, Maxime Villard wrote:
>
> Le 01/07/2019 à 19:40, J. Hannken-Illjes a écrit :
>> Sometimes kmem_alloc() returns an address below
>> VM_MIN_KERNEL_ADDRESS, something like
>> kmem_alloc() -> 0xaba25800a5a8 with
>> VM_MIN_KER
le system or something like
> that?
We also come here with a full vnode cache cleaning vnodes to keep the cache
size below its max calling vrecycle() on un-deleted vnodes.
I suppose the "vp->v_usecount == 1" assert in vrecycle() may fire with
this change as we drop the inter
ir own line so they don't
> * impinge on any of the above either; different kind of activity
> * again.
> */
>krwlock_t v_lock
>__cacheline_aligned(COHERENCY_UNIT);
>krwlock_t v_nc_lock; /* nameca
We have to terminate vrelel() early if we got new references,
diff attached.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig
addendum.diff
Description: Binary data
signature.asc
Description: Message signed with OpenPGP
needs to see this otherwise it fails and
> we go down the slow path instead. The state transition for reclaiming is
> then:
>
> ...
> LOADED
> -> BLOCKED
> confirm that caller still holds the last vnode reference
> -> RECLAIMING
>
r));
> }
> if (vp->v_type != VBLK) {
> - vrele(vp);
> + /* VN_RELE(vp); ?? */
> + vn_close(vp, FREAD|FWRITE, kcred);
> vd->vdev_stat.vs_aux = VDEV_AUX_OPEN_FAILED;
> return (SET_ERROR(EINVAL));
> }
ere.
If you mean misc/55042: Panic when creating a directory on a NFS served ZFS
it should be fixed in -current.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig
signature.asc
Description: Message signed with OpenPGP
interval, began + interval));
> -
> - return (next);
> + return (interval);
> }
This is completely wrong, l2arc_write_interval() must return next time,
not a fixed interval.
> This is on NetBSD-9. I hope I haven't missed something obvious in setup here.
> Does anyon
ZFS filesystem version: 5
> [14.650039] wait 100
> [15.690043] wait 96
> [17.840054] wait 0
As Manuel said this will block forever. Please try the attached diff
that should prevent waits on negative or zero ticks.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
arc.c.diff
Description: Binary data
signature.asc
Description: Message signed with OpenPGP
e /dev/tty00
and hangs hard. The revoke() operation enters spec_node_revoke()
and here it waits forever for sn_iocnt to become zero.
As the read from the other thread set sn_iocnt to one by entering
through spec_io_enter() the system will hang until this read returns.
Am I missing something?
--
J. H
lready serializes VOP_INACTIVE() and all that is
missing is a path to retry the vrelel() if the vnode gained another
reference.
--
J. Hannken-Illjes - hann...@mailbox.org
signature.asc
Description: Message signed with OpenPGP
> On 1. Feb 2022, at 02:14, Taylor R Campbell wrote:
>
>> Date: Mon, 31 Jan 2022 11:15:25 +0100
>> From: "J. Hannken-Illjes"
>>
>> Do you have a recipe so I could try it here?
>
> New draft, and script I've been using for testing. It
eturn ENOENT if IMNT_GONE is set in mnt_iflag.
> I'm not sure if mnt_iflag is even protected against concurrent access
> but vrevoke() racing with dounmount() might be enough.
Flag IMNT_GONE is protected with suspension. Looks like the KASSERT
should become "KASSERT(error == EOPN
; https://mail-index.netbsd.org/source-changes/2022/02/28/msg137219.html
>
> i don't know when this broke. i only really started looking because
> christos said he saw this problem..
I'm now able to reproduce it here -- takes about six hours to trigger.
I suppose vrele
> On 9. Mar 2022, at 02:22, matthew green wrote:
>
> matthew green writes:
>> "J. Hannken-Illjes" writes:
>>> I'm now able to reproduce it here -- takes about six hours to trigger.
>>>
>>> I suppose vrelel() lost a check for new refere
_vnode.c or create a new file vfs_knote.c, to avoid
> having tentacles of vnode guts creep back into places we successfully
> cut them out of before?
Looks good to me, please go ahead.
For me it is generally ok to include vnode_impl.h from all of
kern/vfs_* miscfs/genfs/* and miscfs/specfs/*
p == vp->v_mount)
break;
fstrans_done(mp);
}
or
mp = vp->v_mount;
fstrans_start(mp);
if (mp != vp->v_mount) {
fstrans_done(mp);
return ENOENT;
}
thus avoiding this race and alwa
> On 4. Aug 2023, at 21:48, Jaromír Doleček wrote:
> In a broader view, I have doubts if there is any practical reason to
> even have support for bigger than 64kb block size support at all.
Having tapes with record size > 64k would be a real benefit though.
--
J. Hannken-I
wrong.
- if the reference counting is used to free an unreferenced
object ist is obviously racy
--
J. Hannken-Illjes - hann...@mailbox.org
signature.asc
Description: Message signed with OpenPGP
> someone to hit the space bar vis:
>
> r9 af80b451d080
> r10 81d9a063
> r11 0
> r12 0
> --db_more--
>
> Is there a way to stop this without having to rebuild the kernel.
sysctl -w ddb.lines=0
--
J. Hannken-Illjes - hann...@mailbox.org
> On 15. Dec 2023, at 19:44, Andrew Cagney wrote:
>
> On Fri, 15 Dec 2023 at 11:22, J. Hannken-Illjes wrote:
>
>>> Is there a way to stop this without having to rebuild the kernel.
>>
>> sysctl -w ddb.lines=0
>
> thanks, I'll add that (it won&#
On Tue, Dec 19, 2023 at 07:50:25AM +1030, Brett Lymn wrote:
> On Sat, Sep 02, 2023 at 08:57:03AM +0930, Brett Lymn wrote:
> > On Thu, Aug 31, 2023 at 10:24:07AM +0200, J. Hannken-Illjes wrote:
> > >
> > > I'm short on time, some remarks:
> > >
> >
ner; /* owning process */
> char*khs_name; /* name of this semaphore */
> size_t khs_namelen;/* length of name */
> int khs_state; /* state of this port */
> int khs_wait
201 - 253 of 253 matches
Mail list logo
