< said:
> Can you find any evidence that it's acceptable to interleave multiple
> writers that are doing O_APPEND? At best, to do what you're asking,
> they could be kept from being interleaved from the context of one
> specific NFS client host...
As far as POSIX goes, the standard says that ap
On Fri, Apr 22, 2005 at 11:28:15AM -0400, Garrett Wollman wrote:
> < PROTECTED]> said:
>
>
> > Can you find any evidence that it's acceptable to interleave multiple
> > writers that are doing O_APPEND? At best, to do what you're asking,
> > they could be kept from being interleaved from the cont
On Wed, Apr 20, 2005 at 01:29:10PM -0400, Garrett Wollman wrote:
> < PROTECTED]> said:
>
> > I think the first is more useful behavior than the last. Supporting it
> > should be exactly the same as supporting what happens if the actual
> > filesystem fills up. In this case, the filesystem is bei
< POSIX == SUSv3 these days.
Not quite. POSIX and SUSv3 use the same specification, but don't
require the same things. (Specifically, SUSv3 requires the XSI option
to be implemented.)
-GAWollman
___
freebsd-hackers@freebsd.org mailing list
http://lis
< said:
> I think the first is more useful behavior than the last. Supporting it
> should be exactly the same as supporting what happens if the actual
> filesystem fills up. In this case, the filesystem is being requested to
> write more "than there is room for."
Returning a short write for ope
< said:
> Btw.: I'm not sure write(),writev() and pwrite() are allowed to do short
> writes on regular files... ?
I believe it is the intent of the Standard to prohibit this (a
paragraph in the rationale says that short writes can only happen if
O_NONBLOCK is set, but this is clearly wrong becaus
Marc Olzheim <[EMAIL PROTECTED]> writes:
> Ah, I was reading the SUSv2 page:
>
> http://www.opengroup.org/onlinepubs/009695399/functions/write.html
>
> instead of the POSIX version.
POSIX == SUSv3 these days.
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
On Wed, Apr 20, 2005 at 01:28:39PM -0400, Brian Fundakowski Feldman wrote:
> > It is ok to return partial success if the first chunk of a large write
> > succeeded and a later chunk failed persistently, but not if it cannot be
> > performed as a single NFS transaction.
>
> What is your rationale f
On Wed, Apr 20, 2005 at 01:29:10PM -0400, Garrett Wollman wrote:
> < PROTECTED]> said:
>
> > I think the first is more useful behavior than the last. Supporting it
> > should be exactly the same as supporting what happens if the actual
> > filesystem fills up. In this case, the filesystem is bei
On Wed, Apr 20, 2005 at 07:12:20PM +0200, Jilles Tjoelker wrote:
> On Wed, Apr 20, 2005 at 11:52:33AM -0400, Brian Fundakowski Feldman wrote:
> > On Wed, Apr 20, 2005 at 05:35:28PM +0200, Marc Olzheim wrote:
> > > On Wed, Apr 20, 2005 at 11:20:38AM -0400, Brian Fundakowski Feldman wrote:
> > > > >
On Wed, Apr 20, 2005 at 11:52:33AM -0400, Brian Fundakowski Feldman wrote:
> On Wed, Apr 20, 2005 at 05:35:28PM +0200, Marc Olzheim wrote:
> > On Wed, Apr 20, 2005 at 11:20:38AM -0400, Brian Fundakowski Feldman wrote:
> > > > Btw.: I'm not sure write(),writev() and pwrite() are allowed to do short
On Wed, Apr 20, 2005 at 05:35:28PM +0200, Marc Olzheim wrote:
> On Wed, Apr 20, 2005 at 11:20:38AM -0400, Brian Fundakowski Feldman wrote:
> > Reads should be totally unaffected...
>
> The server was misbehaving. Fixed. :-)
>
> > > Btw.: I'm not sure write(),writev() and pwrite() are allowed to d
On Wed, Apr 20, 2005 at 11:20:38AM -0400, Brian Fundakowski Feldman wrote:
> Reads should be totally unaffected...
The server was misbehaving. Fixed. :-)
> > Btw.: I'm not sure write(),writev() and pwrite() are allowed to do short
> > writes on regular files... ?
>
> Our manpage is incorrect; PO
On Wed, Apr 20, 2005 at 04:38:42PM +0200, Marc Olzheim wrote:
> On Wed, Apr 20, 2005 at 10:24:48AM -0400, Brian Fundakowski Feldman wrote:
> > > It does and it seems to work. The NFS performance drops considerably
> > > though, from 8/9 MByte/s to 3/4 on sequential reads for instance.
> > >
> > >
On Wed, Apr 20, 2005 at 10:24:48AM -0400, Brian Fundakowski Feldman wrote:
> > It does and it seems to work. The NFS performance drops considerably
> > though, from 8/9 MByte/s to 3/4 on sequential reads for instance.
> >
> > kern/79208 is fixed by this indeed, in that I get short writes (in case
On Wed, Apr 20, 2005 at 04:04:09PM +0200, Marc Olzheim wrote:
> On Tue, Apr 19, 2005 at 04:47:23PM -0400, Brian Fundakowski Feldman wrote:
> > This compiles.
>
> It does and it seems to work. The NFS performance drops considerably
> though, from 8/9 MByte/s to 3/4 on sequential reads for instance
On Tue, Apr 19, 2005 at 04:47:23PM -0400, Brian Fundakowski Feldman wrote:
> This compiles.
It does and it seems to work. The NFS performance drops considerably
though, from 8/9 MByte/s to 3/4 on sequential reads for instance.
kern/79208 is fixed by this indeed, in that I get short writes (in ca
On Tue, Apr 19, 2005 at 12:16:16PM -0400, Brian Fundakowski Feldman wrote:
> On Tue, Apr 19, 2005 at 06:09:00PM +0200, Marc Olzheim wrote:
> > On Tue, Apr 19, 2005 at 06:02:58PM +0200, Marc Olzheim wrote:
> > > On Tue, Apr 19, 2005 at 11:18:00AM -0400, Brian Fundakowski Feldman wrote:
> > > > Does
On Tue, Apr 19, 2005 at 06:09:00PM +0200, Marc Olzheim wrote:
> On Tue, Apr 19, 2005 at 06:02:58PM +0200, Marc Olzheim wrote:
> > On Tue, Apr 19, 2005 at 11:18:00AM -0400, Brian Fundakowski Feldman wrote:
> > > Does this work for you?
> >
> > ...
> >
> > cc -c -O -pipe -Wall -Wredundant-decls -W
On Tue, Apr 19, 2005 at 06:02:58PM +0200, Marc Olzheim wrote:
> On Tue, Apr 19, 2005 at 11:18:00AM -0400, Brian Fundakowski Feldman wrote:
> > Does this work for you?
>
> ...
>
> cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
> -Wmissing-prototypes -Wpointer-arith
On Tue, Apr 19, 2005 at 11:18:00AM -0400, Brian Fundakowski Feldman wrote:
> Does this work for you?
...
cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions
-std=c99 -g -nostdinc -I- -I. -I
On Tue, Apr 19, 2005 at 03:32:27PM +0200, Marc Olzheim wrote:
> On Mon, Apr 18, 2005 at 10:33:21PM +0200, Marc Olzheim wrote:
> > On Mon, Apr 18, 2005 at 04:22:13PM -0400, Brian Fundakowski Feldman wrote:
> > > > > http://green.homeunix.org/~green/nfs_client.deadlock.patch
> > > > Hmm, could you ch
On Mon, Apr 18, 2005 at 10:33:21PM +0200, Marc Olzheim wrote:
> On Mon, Apr 18, 2005 at 04:22:13PM -0400, Brian Fundakowski Feldman wrote:
> > > > http://green.homeunix.org/~green/nfs_client.deadlock.patch
> > > Hmm, could you change it into a diff -u ?
> >
> > I replaced the patch with one with -
On Fri, Apr 15, 2005 at 11:07:08AM -0400, Brian Fundakowski Feldman wrote:
> > Is this supposed to fix kern/79208 ?
>
> Yes, it does; would you like to try a more recent version of the patch?
> It's actually against -STABLE, but it needs to be tested in -CURRENT if
> it's going ot try to make it i
On Fri, Apr 15, 2005 at 03:21:08PM +0200, Marc Olzheim wrote:
> On Fri, Apr 15, 2005 at 01:08:21AM -0400, Brian Fundakowski Feldman wrote:
> > I'll spare a lengthy write-up because I think the patch documents it well
> > enough. It certainly appears to fix things here when doing very large
> > blo
On Fri, Apr 15, 2005 at 01:08:21AM -0400, Brian Fundakowski Feldman wrote:
> I'll spare a lengthy write-up because I think the patch documents it well
> enough. It certainly appears to fix things here when doing very large
> block-sized writes, but it also reduces the throughput with those block
>
I'll spare a lengthy write-up because I think the patch documents it well
enough. It certainly appears to fix things here when doing very large
block-sized writes, but it also reduces the throughput with those block
sizes. (I don't think there should be any difference when using reasonable
block
27 matches
Mail list logo