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

[Jeff Liu <jeff.liu@oracle.com>]

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.


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@linux-foundation.org>> wrote:
> 
>     On Wed, 26 Jun 2013 20:34:19 -0700 Sunil Mushran
>     <sunil.mushran at gmail.com <mailto:sunil.mushran@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