[Ocfs2-devel] [PATCH] ocfs2: llseek requires to ocfs2 inode lock for the file in SEEK_END

Joel Becker jlbec at evilplan.org
Sat Jun 29 06:28:36 PDT 2013


On Fri, Jun 28, 2013 at 05:11:25PM +0800, Jeff Liu wrote:
> On 06/28/2013 06:59 AM, Sunil Mushran wrote:
> 
> > The qs is whether this change is required for a real problem or not. If
> > so, what is that logic
> > that gets tripped up by this behaviour.

This is a straight correctness fix.  We take the hit and apply it.  I'll
check the actual patch on that email.

Joel

> 
> 
> IMHO, there have a couple of commands in Coreutils would be affected by this
> behavior:
> - tail(1) with "-c bytes" option.
> - wc(1): when counting only bytes, it will try to figure out the file size
> 	 through lseek (SEEK_END - SEEK_CUR) when counting only bytes.
> 
> Other popular programs need get the file size via SEEK_END only in some corner
> cases.  e.g, if the input file is not a regular file or the utility failed to
> fetch the file size via fstat(2), they will call lseek as an alternative approach,
> like split(1), truncate(1), head(1) with '-c bytes' option.
> 
> Generally, the user applications might fetch the file size through fstat(2) which
> will go through ocfs2_getattr() so that it's safe to us because we perform inode
> re-validation before filling up the generic attributes.
> 
> IOWs, the user application could be changed accordingly to avoid this issue.
> However, this most likely a workaround to some extent, and we have a bug for
> the SEEK_END business.
> 
> As per our current discussion, one big concern of us is regarding the performance
> with this fix, I'd like to consider it from another point of view, that is the user
> should take all the blame to themselves if they would like to run SEEK_END bounds
> operation on OCFS2, does it sounds make sense? :-P.
> If yes, it would be better to consolidate the code comments to indicate the
> performance negatively and it is not advisable to fetch file size via SEEK_END
> on OCFS2.
> 
> Thanks,
> -Jeff
> 
> > 
> > 
> > On Thu, Jun 27, 2013 at 3:08 PM, Andrew Morton
> > <akpm at linux-foundation.org <mailto:akpm at linux-foundation.org>> wrote:
> > 
> >     On Wed, 26 Jun 2013 20:34:19 -0700 Sunil Mushran
> >     <sunil.mushran at gmail.com <mailto:sunil.mushran at gmail.com>> wrote:
> > 
> >     > AFAIR, this behavior has been there since day 1 and changing it
> >     will impact
> >     > performance negatively. I would recommend against making this
> >     change for
> >     > one app.
> > 
> >     Well, it's a bug fix isn't it?  SEEK_END on a 15k file is presently
> >     returning
> >     10k.
> > 
> >     Obviously tradeoffs are involved - is there any way in which this
> >     behaviour can be fixed without serious performance damage?
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Ocfs2-devel mailing list
> > Ocfs2-devel at oss.oracle.com
> > https://oss.oracle.com/mailman/listinfo/ocfs2-devel
> 
> 
> 
> _______________________________________________
> Ocfs2-devel mailing list
> Ocfs2-devel at oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/ocfs2-devel

-- 



More information about the Ocfs2-devel mailing list