[Ocfs2-devel] [patch 09/11] ocfs2: llseek requires ocfs2 inode lock for the file in SEEK_END

Mark Fasheh mfasheh at suse.de
Fri Feb 7 14:44:09 PST 2014


On Thu, Feb 06, 2014 at 03:50:29PM -0800, Andrew Morton wrote:
> On Thu, 6 Feb 2014 15:42:53 -0800 Mark Fasheh <mfasheh at suse.de> wrote:
> 
> > On Fri, Jan 24, 2014 at 12:47:09PM -0800, akpm at linux-foundation.org wrote:
> > > From: Jensen <shencanquan at huawei.com>
> > > Subject: ocfs2: llseek requires ocfs2 inode lock for the file in SEEK_END
> > > 
> > > llseek requires ocfs2 inode lock for updating the file size in SEEK_END. 
> > > because the file size maybe update on another node.
> > > 
> > > This bug can be reproduce the following scenario: at first, we dd a test
> > > fileA, the file size is 10k.
> > 
> > Basically, you want to amke SEEK_END cluster-aware. This patch would be the
> > right way to do it.
> 
> Sunil was worried about the performance impact.  Correctness beats
> performance, but some quantitative testing would be useful?

Performance is my primary concern as well. I thought of writing it up but
realized I don't really have any evidence off the top of my head one way or
the other that this might slow us down.

That said, I kind of question the usefulness of this patch - we got
along pretty well so far without locking in lseek and some random dd(1) test
doesn't really provide a great end-user reason for why we should do this.

I will note that gfs2 locks for SEEK_END.


Testing would help to answer this, yes. Jensen is this something you can do?
I'm not sure exactly what we would run yet though, I have to think about
that (or maybe someone can suggest something).

Thanks,
	--Mark


--
Mark Fasheh



More information about the Ocfs2-devel mailing list