size_t khs_namelen;/* length of name */
> int khs_state; /* state of this port */
> int khs_waiters;
> int khs_count; /* current count */
> lwpid_t khs_latest_holder
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:
> > >
> &
> 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't help
one 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
g.
- 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
> 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
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 always ho
_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/*
> 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 references
.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 vrelel() lost a check for new refer
y return 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 == EOPNOTSUP
> 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 just
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
/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. Hannken-Ill
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
+ 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 anyone else have a
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
> }
> 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));
> }
> @@ -24
s 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
> .
minate 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
of the above either; different kind of activity
> * again.
> */
>krwlock_t v_lock
>__cacheline_aligned(COHERENCY_UNIT);
>krwlock_t v_nc_lock; /* namecache locks */
>krwlock_t v_nc_listlock;
All
t; 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 interlock before taking the lock.
> 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_M
uld 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
mit - 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
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 amd6
2
> 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)
> 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,
> 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 snap
> 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 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 e
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_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 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
> 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 state
> 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 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 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): no
_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)
> 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.
> 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 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
fssconfig "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)
ke to push the lock down 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)
> On 17. May 2017, at 08:59, Paul Goyette <p...@whooppee.com> 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 observ
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 9. Apr 2017, at 19:16, Taylor R Campbell
> <campbell+netbsd-tech-k...@mumble.net> wrote:
>
>> Date: Sun, 9 Apr 2017 18:47:25 +0200
>> From: "J. Hannken-Illjes" <hann...@eis.cs.tu-bs.de>
>>
>>> On 6. Apr 2017, at 11:44, J. Han
> On 6. Apr 2017, at 11:44, J. Hannken-Illjes <hann...@eis.cs.tu-bs.de> wrote:
>
>>
>> On 5. Apr 2017, at 05:14, Chuck Silvers <c...@chuq.com> wrote:
>>
>> have you considered a callback-based interface where the loop
>> is inside the iteratio
needed.
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)
stroy(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)
> On 2. Apr 2017, at 18:19, Taylor R Campbell
> <campbell+netbsd-tech-k...@mumble.net> wrote:
>
>> Date: Sun, 2 Apr 2017 16:34:20 +0200
>> From: "J. Hannken-Illjes" <hann...@eis.cs.tu-bs.de>
>>
>> Looks like your proposal needs som
> On 2. Apr 2017, at 16:34, Taylor R Campbell
> <campbell+netbsd-tech-k...@mumble.net> wrote:
>
>> Date: Sun, 2 Apr 2017 11:09:49 +0200
>> From: "J. Hannken-Illjes" <hann...@eis.cs.tu-bs.de>
>>
>>> On 1. Apr 2017, at 23:03, Taylor R
> On 2. Apr 2017, at 16:05, Taylor R Campbell
> <campbell+netbsd-tech-k...@mumble.net> wrote:
>
>> Date: Sun, 2 Apr 2017 10:47:42 +0200
>> From: "J. Hannken-Illjes" <hann...@eis.cs.tu-bs.de>
>>
>>> On 1. Apr 2017, at 20:41, Taylor R
> On 1. Apr 2017, at 23:03, Taylor R Campbell
> <campbell+netbsd-tech-k...@mumble.net> wrote:
>
>> Date: Thu, 30 Mar 2017 11:21:41 +0200
>> From: "J. Hannken-Illjes" <hann...@eis.cs.tu-bs.de>
>>
>> Plan is to untangle the mountli
node lock is held.
>
> Benefit: 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 ri
.
- 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 19 Feb 2017, at 18:08, Christos Zoulas <chris...@astron.com> wrote:
>
> In article <f1e96c92-0e24-40b1-b500-92cac4452...@eis.cs.tu-bs.de>,
> J. Hannken-Illjes <hann...@eis.cs.tu-bs.de> wrote:
>>
>> Comments or objections anyone?
>
>
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
for 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
it
> e.g. a poor pullup candidate...
>
> --
> David A. Holland
> dholl...@netbsd.org
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
> On 11 Dec 2016, at 22:33, Nick Hudson <sk...@netbsd.org> wrote:
>
> On 12/11/16 21:05, J. Hannken-Illjes wrote:
>>> On 11 Dec 2016, at 21:01, David Holland <dholland-t...@netbsd.org> wrote:
>>>
>>> On a low-memory machine Nick ran into the f
> wait for syncer
> (b) syncer waiting 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)
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)
?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
e device's open() routine is being called twice, 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 ope
> On 20 May 2016, at 18:31, Taylor R Campbell
> <campbell+netbsd-tech-k...@mumble.net> wrote:
>
> Date: Fri, 20 May 2016 16:38:22 +0200
> From: J. Hannken-Illjes <hann...@eis.cs.tu-bs.de>
>
> 1) Objects vnode and vcache_node always exist together so
mments or objections anyone?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
quot; 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)
it.
- Similar races make the claimed mutual exclusion between lock
and mmap similarly unreliable.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
ke 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_
s_reqq_mtx in the whole 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 liv
...
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
On 18 Aug 2015, at 15:06, Joerg Sonnenberger jo...@britannica.bec.de 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
.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
/ 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)
On 01 May 2015, at 20:02, David Holland dholland-t...@netbsd.org 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
On 01 May 2015, at 14:16, Christos Zoulas chris...@astron.com wrote:
In article f40de9d8-f529-4411-9695-2d347e4de...@eis.cs.tu-bs.de,
J. Hannken-Illjes hann...@eis.cs.tu-bs.de wrote:
Our miscfs/syncfs originating from the softdep import is a pseudo
file system with one VOP. Its vnodes get
and 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)
invalid, 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)
, 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)
/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)
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)
- 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)
), 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)
) with 0 being the vnode address.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
On 28 Oct 2014, at 14:37, Emmanuel Dreyfus m...@netbsd.org 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 send a message
On 28 Oct 2014, at 15:43, Emmanuel Dreyfus m...@netbsd.org 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: write and fsync
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 17:55, Emmanuel Dreyfus m...@netbsd.org wrote:
J. Hannken-Illjes hann...@eis.cs.tu-bs.de 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
!= VNOVAL vp-v_size == rvap-va_bytes.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
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)
On 02 Oct 2014, at 06:45, Emmanuel Dreyfus m...@netbsd.org wrote:
J. Hannken-Illjes hann...@eis.cs.tu-bs.de 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 return
On 02 Oct 2014, at 17:23, Emmanuel Dreyfus m...@netbsd.org 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.
GOP_ALLOC
On 02 Oct 2014, at 19:09, Emmanuel Dreyfus m...@netbsd.org wrote:
J. Hannken-Illjes hann...@eis.cs.tu-bs.de 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 finally calls
;
if (EXISTSOP(pmp, FALLOCATE))
return _puffs_vnop_fallocate(vp, off, len);
else
return VOP_PUTPAGES(vp, off, off + len,
PGO_CLEANIT|PGO_SYNCIO);
}
--
Emmanuel Dreyfus
m...@netbsd.org
--
J. Hannken-Illjes
On 24 Aug 2014, at 18:57, J. Hannken-Illjes hann...@eis.cs.tu-bs.de wrote:
snip
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 import
On 25 Aug 2014, at 17:39, Taylor R Campbell riastr...@netbsd.org wrote:
Date: Mon, 25 Aug 2014 15:55:53 +0200
From: J. Hannken-Illjes hann...@eis.cs.tu-bs.de
GCC 4.5.4 disabled builtin memcmp as x86 has no cmpmemsi pattern.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052
On 25 Aug 2014, at 15:55, J. Hannken-Illjes hann...@eis.cs.tu-bs.de wrote:
On 24 Aug 2014, at 18:57, J. Hannken-Illjes hann...@eis.cs.tu-bs.de wrote:
snip
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
- 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 (Germany)
Btw.: my test script is:
#! /bin/sh
mdconfig /dev/md0d 2048000
P=${!}
newfs /dev/rmd0a
mount -t ffs -o log /dev/md0a /mnt
(cd /mnt
,
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
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)
1 - 100 of 221 matches
Mail list logo
