Re: pagecache locking (was: bcachefs status update) merged)

2019-06-19 Thread Dave Chinner
On Wed, Jun 19, 2019 at 12:38:38PM +0200, Jan Kara wrote: > On Tue 18-06-19 07:21:56, Amir Goldstein wrote: > > > > Right, but regardless of the spec we have to consider that the > > > > behaviour of XFS comes from it's Irix heritage (actually from EFS, > > > > the predecessor of XFS from the late

Re: pagecache locking (was: bcachefs status update) merged)

2019-06-19 Thread Jan Kara
On Tue 18-06-19 07:21:56, Amir Goldstein wrote: > > > Right, but regardless of the spec we have to consider that the > > > behaviour of XFS comes from it's Irix heritage (actually from EFS, > > > the predecessor of XFS from the late 1980s) > > > > Sure. And as I mentioned, I think it's technically

Re: pagecache locking (was: bcachefs status update) merged)

2019-06-17 Thread Amir Goldstein
> > Right, but regardless of the spec we have to consider that the > > behaviour of XFS comes from it's Irix heritage (actually from EFS, > > the predecessor of XFS from the late 1980s) > > Sure. And as I mentioned, I think it's technically the nicer guarantee. > > That said, it's a pretty *expensi

Re: pagecache locking (was: bcachefs status update) merged)

2019-06-17 Thread Linus Torvalds
On Mon, Jun 17, 2019 at 3:48 PM Dave Chinner wrote: > > The wording of posix changes every time they release a new version > of the standard, and it's _never_ obvious what behaviour the > standard is actually meant to define. They are always written with > sufficient ambiguity and wiggle room that

Re: pagecache locking (was: bcachefs status update) merged)

2019-06-17 Thread Dave Chinner
On Fri, Jun 14, 2019 at 06:01:07PM -1000, Linus Torvalds wrote: > On Thu, Jun 13, 2019 at 5:08 PM Linus Torvalds > wrote: > > > > I do not believe that posix itself actually requires that at all, > > although extended standards may. > > So I tried to see if I could find what this perhaps alludes

Re: pagecache locking (was: bcachefs status update) merged)

2019-06-14 Thread Linus Torvalds
On Thu, Jun 13, 2019 at 5:08 PM Linus Torvalds wrote: > > I do not believe that posix itself actually requires that at all, > although extended standards may. So I tried to see if I could find what this perhaps alludes to. And I suspect it's not in the read/write thing, but the pthreads side tal

Re: pagecache locking (was: bcachefs status update) merged)

2019-06-14 Thread Linus Torvalds
On Thu, Jun 13, 2019 at 9:31 PM Dave Chinner wrote: > > Yes, they do, I see plenty of cases where the page cache works just > fine because it is still faster than most storage. But that's _not > what I said_. I only quoted one small part of your email, because I wanted to point out how you again

Re: pagecache locking (was: bcachefs status update) merged)

2019-06-14 Thread Kent Overstreet
On Fri, Jun 14, 2019 at 09:55:24AM +1000, Dave Chinner wrote: > On Thu, Jun 13, 2019 at 02:36:25PM -0400, Kent Overstreet wrote: > > On Thu, Jun 13, 2019 at 09:02:24AM +1000, Dave Chinner wrote: > > > On Wed, Jun 12, 2019 at 12:21:44PM -0400, Kent Overstreet wrote: > > > > Ok, I'm totally on board

Re: pagecache locking (was: bcachefs status update) merged)

2019-06-14 Thread Dave Chinner
On Thu, Jun 13, 2019 at 04:30:36PM -1000, Linus Torvalds wrote: > On Thu, Jun 13, 2019 at 1:56 PM Dave Chinner wrote: > > > > That said, the page cache is still far, far slower than direct IO, > > Bullshit, Dave. > > You've made that claim before, and it's been complete bullshit before > too, an

Re: pagecache locking (was: bcachefs status update) merged)

2019-06-13 Thread Linus Torvalds
On Thu, Jun 13, 2019 at 1:56 PM Dave Chinner wrote: > > - buffered read and buffered write can run concurrently if they > don't overlap, but right now they are serialised because that's the > only way to provide POSIX atomic write vs read semantics (only XFS > provides userspace with that guarante

Re: pagecache locking (was: bcachefs status update) merged)

2019-06-13 Thread Linus Torvalds
On Thu, Jun 13, 2019 at 1:56 PM Dave Chinner wrote: > > That said, the page cache is still far, far slower than direct IO, Bullshit, Dave. You've made that claim before, and it's been complete bullshit before too, and I've called you out on it then too. Why do you continue to make this obviousl

Re: pagecache locking (was: bcachefs status update) merged)

2019-06-13 Thread Dave Chinner
On Thu, Jun 13, 2019 at 05:21:12PM -0400, Kent Overstreet wrote: > On Thu, Jun 13, 2019 at 03:13:40PM -0600, Andreas Dilger wrote: > > There are definitely workloads that require multiple threads doing > > non-overlapping > > writes to a single file in HPC. This is becoming an increasingly common

Re: pagecache locking (was: bcachefs status update) merged)

2019-06-13 Thread Dave Chinner
On Thu, Jun 13, 2019 at 02:36:25PM -0400, Kent Overstreet wrote: > On Thu, Jun 13, 2019 at 09:02:24AM +1000, Dave Chinner wrote: > > On Wed, Jun 12, 2019 at 12:21:44PM -0400, Kent Overstreet wrote: > > > Ok, I'm totally on board with returning EDEADLOCK. > > > > > > Question: Would we be ok with r

Re: pagecache locking (was: bcachefs status update) merged)

2019-06-13 Thread Kent Overstreet
On Thu, Jun 13, 2019 at 03:13:40PM -0600, Andreas Dilger wrote: > There are definitely workloads that require multiple threads doing > non-overlapping > writes to a single file in HPC. This is becoming an increasingly common > problem > as the number of cores on a single client increase, since t

pagecache locking (was: bcachefs status update) merged)

2019-06-13 Thread Kent Overstreet
On Thu, Jun 13, 2019 at 09:02:24AM +1000, Dave Chinner wrote: > On Wed, Jun 12, 2019 at 12:21:44PM -0400, Kent Overstreet wrote: > > Ok, I'm totally on board with returning EDEADLOCK. > > > > Question: Would we be ok with returning EDEADLOCK for any IO where the > > buffer is > > in the same addr