Julian Elischer wrote:
On 13/4/17 5:45 am, Rick Macklem wrote:
> I have just committed a patch to head (r316745) which should fix this.
> (It includes code to handle the recent change to head to make the pageouts
> write through the buffer cache.)
>
> It will be MFC'd and should be in 11.1.
> is
On Mon, Apr 17, 2017 at 12:56:43AM +0800, Julian Elischer wrote:
> On 13/4/17 5:45 am, Rick Macklem wrote:
> > I have just committed a patch to head (r316745) which should fix this.
> > (It includes code to handle the recent change to head to make the pageouts
> > write through the buffer cache.)
eeBSD Current
Subject: Re: process killed: text file modification
I can't do commits until I get home in mid-April.
That's why it will be waiting until then.
It should make it into stable/11 in plenty of time for 11.1.
Thanks for your help with this, rick
__
rick
From: owner-freebsd-curr...@freebsd.org on
behalf of Rick Macklem
Sent: Friday, March 24, 2017 4:14:45 PM
To: Konstantin Belousov
Cc: Gergely Czuczy; Dimitry Andric; Ian Lepore; FreeBSD Current
Subject: Re: process killed: text file modification
I can't do commits until I g
behalf of Konstantin Belousov
Sent: Friday, March 24, 2017 3:01:41 AM
To: Rick Macklem
Cc: Gergely Czuczy; Dimitry Andric; Ian Lepore; FreeBSD Current
Subject: Re: process killed: text file modification
On Thu, Mar 23, 2017 at 09:39:00PM +, Rick Macklem wrote:
> Try whatever you like. However, if
On Thu, Mar 23, 2017 at 09:39:00PM +, Rick Macklem wrote:
> Try whatever you like. However, if the case that failed before doesn't fail
> now,
> I'd call the test a success.
>
> Thanks, rick
> ps: It looks like Kostik is going to work on converting the NFS
> vop_putpages() to
> using t
t by
mid-April,
I will commit this patch to help fix things in the meantime.
From: Gergely Czuczy
Sent: Thursday, March 23, 2017 2:25:11 AM
To: Rick Macklem; Konstantin Belousov
Cc: Dimitry Andric; Ian Lepore; FreeBSD Current
Subject: Re: process ki
On 2017. 03. 21. 3:40, Rick Macklem wrote:
Gergely Czuczy wrote:
[stuff snipped]
Actually I want to test it, but you guys are so vehemently discussing
it, I thought it would be better to do so, once you guys settled your
analysis on the code. Also, me not having the problem occurring, I don't
th
On Thu, Mar 23, 2017 at 12:55:09AM +, Rick Macklem wrote:
> Wow, this is looking good to me. I had thought that the simple way to make
> ncl_putpages() go through the buffer cache was to replace ncl_writerpc() with
> VOP_WRITE(). My concern was all the memory<->memory copying that would
> go on
On 2017. 03. 21. 3:40, Rick Macklem wrote:
Gergely Czuczy wrote:
[stuff snipped]
Actually I want to test it, but you guys are so vehemently discussing
it, I thought it would be better to do so, once you guys settled your
analysis on the code. Also, me not having the problem occurring, I don't
th
Konstantin Belousov wrote:
[stuff snipped]
> Below is something to discuss. This is not finished, but it worked for
> the simple tests I performed. Clustering should be somewhat handled by
> the ncl_write() as is. As an additional advantage, I removed the now
> unneeded phys buffer allocation.
>
>
On Tue, Mar 21, 2017 at 09:41:19PM +, Rick Macklem wrote:
> Konstantin Belousov wrote:
> > Anyway, my position is that nfs VOP_PUTPAGES() should do write through
> > buffer cache, not issuing the direct rpc call with the pages as source.
> Hmm. Interesting idea. Since a "struct buf" can only re
Konstantin Belousov wrote:
[stuff snipped]
> By 'impossible' I mean some arbitrary combination of bytes which were
> written by many means to the file at arbitrary moments. In other words,
> the file content, or even a single page/block content is not atomic
> WRT the client updates.
Yes. For mult
On Tue, Mar 21, 2017 at 02:30:38AM +, Rick Macklem wrote:
> Konstantin Belousov wrote:
> [stuff snipped]
> > Yes, I have to somewhat retract my claims, but then I have another set
> > of surprises.
> Righto.
>
> > I realized (remembered) that nfs has its own VOP_PUTPAGES() method.
> > Implemen
On 2017. 03. 21. 3:40, Rick Macklem wrote:
Gergely Czuczy wrote:
[stuff snipped]
Actually I want to test it, but you guys are so vehemently discussing
it, I thought it would be better to do so, once you guys settled your
analysis on the code. Also, me not having the problem occurring, I don't
th
Gergely Czuczy wrote:
[stuff snipped]
> Actually I want to test it, but you guys are so vehemently discussing
> it, I thought it would be better to do so, once you guys settled your
> analysis on the code. Also, me not having the problem occurring, I don't
> think would mean it's solved, since that
Konstantin Belousov wrote:
[stuff snipped]
> Yes, I have to somewhat retract my claims, but then I have another set
> of surprises.
Righto.
> I realized (remembered) that nfs has its own VOP_PUTPAGES() method.
> Implementation seems to directly initiate write RPC request using the
> pages as the s
On Sun, Mar 19, 2017 at 08:52:50PM +, Rick Macklem wrote:
> Kostik wrote:
> [stuff snipped]
> >> >> Dirty pages are flushed by writes, so if we have a set of dirty pages
> >> >> and
> >> >> async vm_object_page_clean() is called on the vnode' vm_object, we get
> >> >> a bunch of delayed-write
On 2017. 03. 19. 21:52, Rick Macklem wrote:
Kostik wrote:
[stuff snipped]
Dirty pages are flushed by writes, so if we have a set of dirty pages and
async vm_object_page_clean() is called on the vnode' vm_object, we get
a bunch of delayed-write AKA dirty buffers. This is possible even after
VO
Kostik wrote:
[stuff snipped]
>> >> Dirty pages are flushed by writes, so if we have a set of dirty pages and
>> >> async vm_object_page_clean() is called on the vnode' vm_object, we get
>> >> a bunch of delayed-write AKA dirty buffers. This is possible even after
>> >> VOP_CLOSE() was done, e.g.
On Fri, Mar 17, 2017 at 09:23:00PM +, Rick Macklem wrote:
> Dimitry Andric wrote:
> >On 17 Mar 2017, at 15:19, Konstantin Belousov wrote:
> >>
> >> On Fri, Mar 17, 2017 at 01:53:46PM +, Rick Macklem wrote:
> >>> Well, I don't mind adding ncl_flush(), but it shouldn't be
> >>> necessary. I
Dimitry Andric wrote:
>On 17 Mar 2017, at 15:19, Konstantin Belousov wrote:
>>
>> On Fri, Mar 17, 2017 at 01:53:46PM +, Rick Macklem wrote:
>>> Well, I don't mind adding ncl_flush(), but it shouldn't be
>>> necessary. I actually had it in the first
>>> rendition of the patch, but took it out b
On 17 Mar 2017, at 15:19, Konstantin Belousov wrote:
>
> On Fri, Mar 17, 2017 at 01:53:46PM +, Rick Macklem wrote:
>> Well, I don't mind adding ncl_flush(), but it shouldn't be
>> necessary. I actually had it in the first
>> rendition of the patch, but took it out because it should happen
>>
On Fri, Mar 17, 2017 at 01:53:46PM +, Rick Macklem wrote:
> Well, I don't mind adding ncl_flush(), but it shouldn't be
> necessary. I actually had it in the first
> rendition of the patch, but took it out because it should happen
> on the VOP_CLOSE() if any writing to the buffer cache happened
pore; Gergely Czuczy; FreeBSD Current
Subject: Re: process killed: text file modification
On Fri, Mar 17, 2017 at 03:10:57AM +, Rick Macklem wrote:
> Hope you don't mind a top post...
> Attached is a little patch you could test maybe?
>
> rick
> ___
m
> Sent: Thursday, March 16, 2017 9:57:23 PM
> To: Dimitry Andric; Ian Lepore
> Cc: Gergely Czuczy; FreeBSD Current
> Subject: Re: process killed: text file modification
>
> Dimitry Andric wrote:
> [lots of stuff snipped]
> > I'm also running into this problem, bu
zuczy; FreeBSD Current
Subject: Re: process killed: text file modification
Dimitry Andric wrote:
[lots of stuff snipped]
> I'm also running into this problem, but while using lld. I must set
> vfs.timestamp_precision to 1 (e.g. sec + ns accurate to 1/HZ) on both
> the client and the serv
Dimitry Andric wrote:
[lots of stuff snipped]
> I'm also running into this problem, but while using lld. I must set
> vfs.timestamp_precision to 1 (e.g. sec + ns accurate to 1/HZ) on both
> the client and the server, to make it work.
>
> Instead of GNU ld, lld uses mmap to write to the output exe
> On 12 Mar 2017, at 18:47, Ian Lepore wrote:
>
> On Thu, 2017-03-09 at 21:07 +0100, Gergely Czuczy wrote:
>>
>> On 2017. 03. 09. 20:47, Gergely Czuczy wrote:
>>>
>>>
>>>
>>> On 2017. 03. 09. 19:44, John Baldwin wrote:
On Thursday, March 09, 2017 03:31:56 PM Gergely Czuczy wrote:
On Thu, 2017-03-09 at 21:07 +0100, Gergely Czuczy wrote:
>
> On 2017. 03. 09. 20:47, Gergely Czuczy wrote:
> >
> >
> >
> > On 2017. 03. 09. 19:44, John Baldwin wrote:
> > >
> > > On Thursday, March 09, 2017 03:31:56 PM Gergely Czuczy wrote:
> > > >
> > > > [+freebsd-fs]
> > > >
> > > >
> >
On 2017. 03. 09. 20:47, Gergely Czuczy wrote:
On 2017. 03. 09. 19:44, John Baldwin wrote:
On Thursday, March 09, 2017 03:31:56 PM Gergely Czuczy wrote:
[+freebsd-fs]
On 2017. 03. 09. 14:20, Gergely Czuczy wrote:
On 2017. 03. 09. 11:27, Gergely Czuczy wrote:
Hello,
I'm trying to build a
On 2017. 03. 09. 19:44, John Baldwin wrote:
On Thursday, March 09, 2017 03:31:56 PM Gergely Czuczy wrote:
[+freebsd-fs]
On 2017. 03. 09. 14:20, Gergely Czuczy wrote:
On 2017. 03. 09. 11:27, Gergely Czuczy wrote:
Hello,
I'm trying to build a few things from ports on an rpi3, the ports
coll
On Thursday, March 09, 2017 03:31:56 PM Gergely Czuczy wrote:
> [+freebsd-fs]
>
>
> On 2017. 03. 09. 14:20, Gergely Czuczy wrote:
> > On 2017. 03. 09. 11:27, Gergely Czuczy wrote:
> >> Hello,
> >>
> >> I'm trying to build a few things from ports on an rpi3, the ports
> >> collection is mounted o
[+freebsd-fs]
On 2017. 03. 09. 14:20, Gergely Czuczy wrote:
On 2017. 03. 09. 11:27, Gergely Czuczy wrote:
Hello,
I'm trying to build a few things from ports on an rpi3, the ports
collection is mounted over NFS from another machine. When it's trying
to build pkg i'm getting the error message
On 2017. 03. 09. 11:27, Gergely Czuczy wrote:
Hello,
I'm trying to build a few things from ports on an rpi3, the ports
collection is mounted over NFS from another machine. When it's trying
to build pkg i'm getting the error message in syslog:
rpi3 kernel: pid 4451 (sh), uid 0, was killed: te
Hello,
I'm trying to build a few things from ports on an rpi3, the ports
collection is mounted over NFS from another machine. When it's trying to
build pkg i'm getting the error message in syslog:
rpi3 kernel: pid 4451 (sh), uid 0, was killed: text file modification
The report to pkg@:
https
36 matches
Mail list logo
