On Tue, 21 Dec 2010, Christos Zoulas wrote:
> Modified Files:
> src/bin/cp: cp.1 cp.c utils.c
>
> Log Message:
> Add -a archive flag. from Aleksey Cheusov
Please add a note under STANDARDS in the man page saying that
"-a" is non-standard.
--apb (Alan Barrett)
On Mon, Oct 25, 2010 at 05:49:11PM +0100, David Laight wrote:
> > No, since in general the file is also being extended (certainly in
> > this case it is) it also has to lock the file size, and that's going
> > to deny stat() until it's done.
>
> A stat request during a write can safely return
On Tue, Oct 26, 2010 at 05:05:28AM +1100, matthew green wrote:
>
> > On Mon, Oct 25, 2010 at 08:52:43AM +0100, Matthias Scheler wrote:
> > > On Sun, Oct 24, 2010 at 10:56:40PM +, David Holland wrote:
> > > > Anyway, ISTM that writing from the mmap buffer in say 64K chunks would
> > > > retain
On Mon, Oct 25, 2010 at 06:46:36PM +0200, Joerg Sonnenberger wrote:
> On Mon, Oct 25, 2010 at 06:41:11PM +0200, Juergen Hannken-Illjes wrote:
> > > Do we implement MADV_WILLNEED?
> >
> > According to the man page "This WILL NOT fault pages in from backing store".
>
> The version of the man page I
> On Mon, Oct 25, 2010 at 08:52:43AM +0100, Matthias Scheler wrote:
> > On Sun, Oct 24, 2010 at 10:56:40PM +, David Holland wrote:
> > > Anyway, ISTM that writing from the mmap buffer in say 64K chunks would
> > > retain nearly all the advantages and get rid of the latency problem.
> >
> > Th
On Mon, Oct 25, 2010 at 06:41:11PM +0200, Juergen Hannken-Illjes wrote:
> > Do we implement MADV_WILLNEED?
>
> According to the man page "This WILL NOT fault pages in from backing store".
The version of the man page I have says "It might or might not fault
pages in from backing store".
Joerg
On Sun, Oct 24, 2010 at 10:56:40PM +, David Holland wrote:
> >
> > I think write() only needs to lock the the file enough to ensure that
> > the file offset is correct.
>
> No, since in general the file is also being extended (certainly in
> this case it is) it also has to lock the file si
On Mon, Oct 25, 2010 at 11:17:22AM +0200, Juergen Hannken-Illjes wrote:
> On Sun, Oct 24, 2010 at 05:21:06AM +, David Holland wrote:
> > On Fri, Oct 22, 2010 at 05:56:06PM +, Antti Kantee wrote:
> > > Disable mmap path. With the current vnode locking scheme it has
> > > a very annoying p
On Mon, Oct 25, 2010 at 06:30:54PM +0200, Joerg Sonnenberger wrote:
> On Mon, Oct 25, 2010 at 11:17:22AM +0200, Juergen Hannken-Illjes wrote:
> > On Sun, Oct 24, 2010 at 05:21:06AM +, David Holland wrote:
> > > On Fri, Oct 22, 2010 at 05:56:06PM +, Antti Kantee wrote:
> > > > Disable mmap
On Mon, Oct 25, 2010 at 11:17:22AM +0200, Juergen Hannken-Illjes wrote:
> On Sun, Oct 24, 2010 at 05:21:06AM +, David Holland wrote:
> > On Fri, Oct 22, 2010 at 05:56:06PM +, Antti Kantee wrote:
> > > Disable mmap path. With the current vnode locking scheme it has
> > > a very annoying p
On Sun, Oct 24, 2010 at 05:21:06AM +, David Holland wrote:
> On Fri, Oct 22, 2010 at 05:56:06PM +, Antti Kantee wrote:
> > Disable mmap path. With the current vnode locking scheme it has
> > a very annoying property: if the source media is slow (like a slow
> > network), the target file
On Mon, Oct 25, 2010 at 08:52:43AM +0100, Matthias Scheler wrote:
> On Sun, Oct 24, 2010 at 10:56:40PM +, David Holland wrote:
> > Anyway, ISTM that writing from the mmap buffer in say 64K chunks would
> > retain nearly all the advantages and get rid of the latency problem.
>
> The way the cod
On Sun, Oct 24, 2010 at 10:56:40PM +, David Holland wrote:
> Anyway, ISTM that writing from the mmap buffer in say 64K chunks would
> retain nearly all the advantages and get rid of the latency problem.
The way the code is currently written it only uses mmap(2) for
files smaller than 8MB anywa
(adding tech-kern because this seems likely to become lengthy; if
following up please drop source-changes-d)
On Sun, Oct 24, 2010 at 11:30:43AM +0100, David Laight wrote:
> > > [mmap mode disabled in cp due to long vnode lock waits]
> >
> > Because individual write() calls are supposed to be at
On Sun, Oct 24, 2010 at 05:21:06AM +, David Holland wrote:
>
> Because individual write() calls are supposed to be atomic, I don't
> think there is such a thing as a locking improvement that'll help with
> this behavior. :-/
I think write() only needs to lock the the file enough to ensure tha
On Fri, Oct 22, 2010 at 05:56:06PM +, Antti Kantee wrote:
> Disable mmap path. With the current vnode locking scheme it has
> a very annoying property: if the source media is slow (like a slow
> network), the target file will be locked for the duration of the
> entire max 8MB write and cau
16 matches
Mail list logo