On Mon, Jul 01, 2013 at 09:38:31AM +0800, Jensen wrote:
On 2013/6/29 21:37, Joel Becker wrote:
On Thu, Jun 20, 2013 at 04:23:59PM +0800, shencanquan wrote:
llseek requires ocfs2 inode lock for updating the file size in SEEK_END.
because the file size maybe update on another node.
if it
On 2013/6/29 21:37, Joel Becker wrote:
On Thu, Jun 20, 2013 at 04:23:59PM +0800, shencanquan wrote:
llseek requires ocfs2 inode lock for updating the file size in SEEK_END.
because the file size maybe update on another node.
if it not . after call llseek in SEEK_END. the position is old.
On Thu, Jun 20, 2013 at 04:23:59PM +0800, shencanquan wrote:
llseek requires ocfs2 inode lock for updating the file size in SEEK_END.
because the file size maybe update on another node.
if it not . after call llseek in SEEK_END. the position is old.
this bug can be reproduce the following
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
On 2013/6/27 11:34, Sunil Mushran 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.
I think it will impact the performance negatively. but I think it is very
very little,
On Thu, 20 Jun 2013 16:23:59 +0800 shencanquan shencanq...@huawei.com wrote:
llseek requires ocfs2 inode lock for updating the file size in SEEK_END.
because the file size maybe update on another node.
if it not . after call llseek in SEEK_END. the position is old.
this bug can be reproduce
On 2013/6/27 5:18, Andrew Morton wrote:
On Thu, 20 Jun 2013 16:23:59 +0800 shencanquan shencanq...@huawei.com wrote:
llseek requires ocfs2 inode lock for updating the file size in SEEK_END.
because the file size maybe update on another node.
if it not . after call llseek in SEEK_END. the
On Thu, 27 Jun 2013 09:19:52 +0800 shencanquan shencanq...@huawei.com wrote:
On 2013/6/27 5:18, Andrew Morton wrote:
My guess is that there is some other code path which is modifying
inode-i_size without holding inode-i_mutex, and while holding
ocfs2_inode_lock(). If so, that code is
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.
On Wed, Jun 26, 2013 at 6:50 PM, shencanquan shencanq...@huawei.com wrote:
On 2013/6/27 9:25, Andrew Morton wrote:
On Thu, 27 Jun
llseek requires ocfs2 inode lock for updating the file size in SEEK_END.
because the file size maybe update on another node.
if it not . after call llseek in SEEK_END. the position is old.
this bug can be reproduce the following scenario:
at first ,we dd a test fileA,the file size is 10k.
on
10 matches
Mail list logo
