Bug 1369349 - enable trash, then truncate a large file lead to glusterfsd segfault
Summary: enable trash, then truncate a large file lead to glusterfsd segfault
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: GlusterFS
Classification: Community
Component: trash-xlator
Version: mainline
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Jiffin
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-23 07:57 UTC by jiademing.dd
Modified: 2019-05-09 20:07 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-05-09 20:07:05 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:

Attachments (Terms of Use)

Description jiademing.dd 2016-08-23 07:57:00 UTC 
Description of problem:
  enable trash, then truncate a large file lead to glusterfsd segfault

1) enable trash, then set trash-max-filesize: 1GB
Volume Name: test
Type: Distribute
Volume ID: fa5ccae9-4de6-4fa6-9f2b-e1f083cffecb
Status: Started
Snapshot Count: 0
Number of Bricks: 2
Transport-type: tcp
Bricks:
Brick1: node-1:/disk1
Brick2: node-1:/disk2
Options Reconfigured:
features.trash: enable
features.trash-max-filesize: 1GB
transport.address-family: inet
performance.readdir-ahead: on

2) dd if=/dev/zero of=/mountpoint/hello bs=1M count=900

3)truncate --size 1024000 /mountpoint/hello

Actual results:
truncate: failed to truncate ‘/cluster2/test/hello’ at 1024000 bytes: Transport endpoint is not connected

Expected results:
truncate successful

Version-Release number of selected component (if applicable):
master commit efbae0fef5399a8826782b02140f44edaea0dac3


gdb bt:
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f621e402d17 in vfprintf () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007f621e402d17 in vfprintf () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f621e4299db in vsprintf () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007f621e40d5c7 in sprintf () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x00007f621e4c40f7 in backtrace_symbols () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x00007f621f000493 in _gf_msg_backtrace (stacksize=-219040608, stacksize@entry=5, callstr=0x7f61f2f1bf20 "", strsize=4096) at logging.c:1135
#5  0x00007f621f001571 in _gf_msg (domain=0x7f6214007810 "test-posix", file=file@entry=0x7f6218fa4ffb "posix.c", function=function@entry=0x7f6218fa8080 <__FUNCTION__.19690> "_fill_writev_xdata", 
    line=line@entry=3242, level=level@entry=GF_LOG_ERROR, errnum=errnum@entry=22, trace=trace@entry=1, msgid=msgid@entry=113001, fmt=fmt@entry=0x7f6218fa596b "fd: %p inode: %pgfid:%s") at logging.c:2046
#6  0x00007f6218f9432f in _fill_writev_xdata (fd=fd@entry=0x7f621f2ed0f8, xdata=xdata@entry=0x0, this=this@entry=0x7f6214006c70, is_append=<optimized out>) at posix.c:3239
#7  0x00007f6218f94578 in posix_writev (frame=0x7f621ce51148, this=0x7f6214006c70, fd=0x7f621f2ed0f8, vector=<optimized out>, count=<optimized out>, offset=136970240, flags=0, iobref=0x7f61dc0803e0, xdata=0x0)
    at posix.c:3376
#8  0x00007f621874eb83 in trash_truncate_readv_cbk (frame=frame@entry=0x7f621cde6260, cookie=<optimized out>, this=0x7f62140096e0, op_ret=op_ret@entry=131072, op_errno=<optimized out>, 
    vector=vector@entry=0x7f61f2f1d330, count=count@entry=1, stbuf=stbuf@entry=0x7f61f2f1d340, iobuf=iobuf@entry=0x7f61dc0803e0, xdata=xdata@entry=0x0) at trash.c:1188
#9  0x00007f6218f875aa in posix_readv (frame=0x7f621ce51074, this=<optimized out>, fd=<optimized out>, size=<optimized out>, offset=<optimized out>, flags=<optimized out>, xdata=0x0) at posix.c:3141
#10 0x00007f621874f09d in trash_truncate_writev_cbk (frame=0x7f621cde6260, cookie=<optimized out>, this=0x7f62140096e0, op_ret=<optimized out>, op_errno=<optimized out>, prebuf=<optimized out>, 
    postbuf=0x7f61f2f1d550, xdata=0x0) at trash.c:1227
#11 0x00007f6218f9482b in posix_writev (frame=0x7f621ce50fa0, this=<optimized out>, fd=<optimized out>, vector=<optimized out>, count=<optimized out>, offset=136839168, flags=0, iobref=0x7f61dc080280, 
    xdata=0x0) at posix.c:3423
#12 0x00007f621874eb83 in trash_truncate_readv_cbk (frame=frame@entry=0x7f621cde6260, cookie=<optimized out>, this=0x7f62140096e0, op_ret=op_ret@entry=131072, op_errno=<optimized out>, 
    vector=vector@entry=0x7f61f2f1d700, count=count@entry=1, stbuf=stbuf@entry=0x7f61f2f1d710, iobuf=iobuf@entry=0x7f61dc080280, xdata=xdata@entry=0x0) at trash.c:1188
#13 0x00007f6218f875aa in posix_readv (frame=0x7f621ce50ecc, this=<optimized out>, fd=<optimized out>, size=<optimized out>, offset=<optimized out>, flags=<optimized out>, xdata=0x0) at posix.c:3141
#14 0x00007f621874f09d in trash_truncate_writev_cbk (frame=0x7f621cde6260, cookie=<optimized out>, this=0x7f62140096e0, op_ret=<optimized out>, op_errno=<optimized out>, prebuf=<optimized out>, 
    postbuf=0x7f61f2f1d920, xdata=0x0) at trash.c:1227
#15 0x00007f6218f9482b in posix_writev (frame=0x7f621ce50df8, this=<optimized out>, fd=<optimized out>, vector=<optimized out>, count=<optimized out>, offset=136708096, flags=0, iobref=0x7f61dc080120, 
    xdata=0x0) at posix.c:3423
#16 0x00007f621874eb83 in trash_truncate_readv_cbk (frame=frame@entry=0x7f621cde6260, cookie=<optimized out>, this=0x7f62140096e0, op_ret=op_ret@entry=131072, op_errno=<optimized out>, 
    vector=vector@entry=0x7f61f2f1dad0, count=count@entry=1, stbuf=stbuf@entry=0x7f61f2f1dae0, iobuf=iobuf@entry=0x7f61dc080120, xdata=xdata@entry=0x0) at trash.c:1188
#17 0x00007f6218f875aa in posix_readv (frame=0x7f621ce50d24, this=<optimized out>, fd=<optimized out>, size=<optimized out>, offset=<optimized out>, flags=<optimized out>, xdata=0x0) at posix.c:3141
#18 0x00007f621874f09d in trash_truncate_writev_cbk (frame=0x7f621cde6260, cookie=<optimized out>, this=0x7f62140096e0, op_ret=<optimized out>, op_errno=<optimized out>, prebuf=<optimized out>, 
    postbuf=0x7f61f2f1dcf0, xdata=0x0) at trash.c:1227
#19 0x00007f6218f9482b in posix_writev (frame=0x7f621ce50c50, this=<optimized out>, fd=<optimized out>, vector=<optimized out>, count=<optimized out>, offset=136577024, flags=0, iobref=0x7f61dc07ffc0, 
    xdata=0x0) at posix.c:3423
#20 0x00007f621874eb83 in trash_truncate_readv_cbk (frame=frame@entry=0x7f621cde6260, cookie=<optimized out>, this=0x7f62140096e0, op_ret=op_ret@entry=131072, op_errno=<optimized out>, 
    vector=vector@entry=0x7f61f2f1dea0, count=count@entry=1, stbuf=stbuf@entry=0x7f61f2f1deb0, iobuf=iobuf@entry=0x7f61dc07ffc0, xdata=xdata@entry=0x0) at trash.c:1188
#21 0x00007f6218f875aa in posix_readv (frame=0x7f621ce50b7c, this=<optimized out>, fd=<optimized out>, size=<optimized out>, offset=<optimized out>, flags=<optimized out>, xdata=0x0) at posix.c:3141
#22 0x00007f621874f09d in trash_truncate_writev_cbk (frame=0x7f621cde6260, cookie=<optimized out>, this=0x7f62140096e0, op_ret=<optimized out>, op_errno=<optimized out>, prebuf=<optimized out>, 
    postbuf=0x7f61f2f1e0c0, xdata=0x0) at trash.c:1227
#23 0x00007f6218f9482b in posix_writev (frame=0x7f621ce50aa8, this=<optimized out>, fd=<optimized out>, vector=<optimized out>, count=<optimized out>, offset=136445952, flags=0, iobref=0x7f61dc07fe60, 
    xdata=0x0) at posix.c:3423
#24 0x00007f621874eb83 in trash_truncate_readv_cbk (frame=frame@entry=0x7f621cde6260, cookie=<optimized out>, this=0x7f62140096e0, op_ret=op_ret@entry=131072, op_errno=<optimized out>, 
    vector=vector@entry=0x7f61f2f1e270, count=count@entry=1, stbuf=stbuf@entry=0x7f61f2f1e280, iobuf=iobuf@entry=0x7f61dc07fe60, xdata=xdata@entry=0x0) at trash.c:1188
#25 0x00007f6218f875aa in posix_readv (frame=0x7f621ce509d4, this=<optimized out>, fd=<optimized out>, size=<optimized out>, offset=<optimized out>, flags=<optimized out>, xdata=0x0) at posix.c:3141
#26 0x00007f621874f09d in trash_truncate_writev_cbk (frame=0x7f621cde6260, cookie=<optimized out>, this=0x7f62140096e0, op_ret=<optimized out>, op_errno=<optimized out>, prebuf=<optimized out>, 
    postbuf=0x7f61f2f1e490, xdata=0x0) at trash.c:1227
#27 0x00007f6218f9482b in posix_writev (frame=0x7f621ce50900, this=<optimized out>, fd=<optimized out>, vector=<optimized out>, count=<optimized out>, offset=136314880, flags=0, iobref=0x7f61dc07fd00, 
.
.
.
.
.
.
.
.
    xdata=0x0) at posix.c:3423
#4184 0x00007f621874eb83 in trash_truncate_readv_cbk (frame=frame@entry=0x7f621cde6260, cookie=<optimized out>, this=0x7f62140096e0, op_ret=op_ret@entry=131072, op_errno=<optimized out>, 
    vector=vector@entry=0x7f61f3015f70, count=count@entry=1, stbuf=stbuf@entry=0x7f61f3015f80, iobuf=iobuf@entry=0x7f61dc001d80, xdata=xdata@entry=0x0) at trash.c:1188
#4185 0x00007f6218f875aa in posix_readv (frame=0x7f621cde579c, this=<optimized out>, fd=<optimized out>, size=<optimized out>, offset=<optimized out>, flags=<optimized out>, xdata=0x0) at posix.c:3141
#4186 0x00007f621874f09d in trash_truncate_writev_cbk (frame=0x7f621cde6260, cookie=<optimized out>, this=0x7f62140096e0, op_ret=<optimized out>, op_errno=<optimized out>, prebuf=<optimized out>, 
    postbuf=0x7f61f3016190, xdata=0x0) at trash.c:1227
#4187 0x00007f6218f9482b in posix_writev (frame=0x7f621cde6ecc, this=<optimized out>, fd=<optimized out>, vector=<optimized out>, count=<optimized out>, offset=0, flags=0, iobref=0x7f61dc001600, xdata=0x0)
    at posix.c:3423
#4188 0x00007f621874eb83 in trash_truncate_readv_cbk (frame=frame@entry=0x7f621cde6260, cookie=<optimized out>, this=0x7f62140096e0, op_ret=op_ret@entry=131072, op_errno=<optimized out>, 
    vector=vector@entry=0x7f61f3016340, count=count@entry=1, stbuf=stbuf@entry=0x7f61f3016350, iobuf=iobuf@entry=0x7f61dc001600, xdata=xdata@entry=0x0) at trash.c:1188
#4189 0x00007f6218f875aa in posix_readv (frame=0x7f621cde4cd8, this=<optimized out>, fd=<optimized out>, size=<optimized out>, offset=<optimized out>, flags=<optimized out>, xdata=0x0) at posix.c:3141
#4190 0x00007f621874fed9 in trash_truncate_open_cbk (frame=frame@entry=0x7f621cde6260, cookie=<optimized out>, this=0x7f62140096e0, op_ret=<optimized out>, op_errno=op_errno@entry=0, 
    fd=fd@entry=0x7f621f2ed184, xdata=xdata@entry=0x0) at trash.c:1273
#4191 0x00007f6218f82975 in posix_open (frame=0x7f621cde5028, this=<optimized out>, loc=<optimized out>, flags=<optimized out>, fd=0x7f621f2ed184, xdata=<optimized out>) at posix.c:3047
#4192 0x00007f621875718e in trash_truncate_create_cbk (frame=0x7f621cde6260, cookie=<optimized out>, this=0x7f62140096e0, op_ret=<optimized out>, op_errno=<optimized out>, fd=<optimized out>, 
    inode=0x7f61f326d2a0, buf=0x7f61f3017850, preparent=0x7f61f30178c0, postparent=0x7f61f3017930, xdata=0x0) at trash.c:1370
#4193 0x00007f6218f834df in posix_create (frame=0x7f621cde4564, this=0x7f6214006c70, loc=<optimized out>, flags=<optimized out>, mode=<optimized out>, umask=<optimized out>, fd=0x7f621f2ed0f8, xdata=0x0)
    at posix.c:2948
---Type <return> to continue, or q <return> to quit---
#4194 0x00007f621875d499 in trash_truncate_stat_cbk (frame=0x7f621cde6260, cookie=<optimized out>, this=0x7f62140096e0, op_ret=<optimized out>, op_errno=0, buf=0x7f61f3018af0, xdata=0x0) at trash.c:1686
#4195 0x00007f6218f7eab2 in posix_fstat (frame=0x7f621cde55f4, this=<optimized out>, fd=<optimized out>, xdata=<optimized out>) at posix.c:5856
#4196 0x00007f621875ea16 in trash_ftruncate (frame=0x7f621cde6260, this=0x7f62140096e0, fd=0x7f621f2ed06c, offset=<optimized out>, xdata=0x0) at trash.c:1882
#4197 0x00007f6218536bcd in ctr_ftruncate (frame=0x7f621cde6df8, this=0x7f621400ae80, fd=0x7f621f2ed06c, offset=1024000, xdata=0x0) at changetimerecorder.c:791

#4198 0x00007f6213de9700 in changelog_ftruncate (frame=0x7f621cde48b4, this=0x7f621400db00, fd=0x7f621f2ed06c, offset=1024000, xdata=0x0) at changelog.c:1805
#4199 0x00007f6213bd500d in br_stub_ftruncate (frame=0x7f621cde50fc, this=0x7f621400f3a0, fd=0x7f621f2ed06c, offset=1024000, xdata=0x0) at bit-rot-stub.c:2000
#4200 0x00007f621f078cde in default_ftruncate (frame=0x7f621cde50fc, this=0x7f6214010a10, fd=0x7f621f2ed06c, offset=1024000, xdata=0x0) at defaults.c:2801
#4201 0x00007f621379e5e5 in truncate_stat_cbk (frame=0x7f621cde7990, cookie=<optimized out>, this=0x7f6214011e20, op_ret=0, op_errno=<optimized out>, buf=0x7f61f3019860, xdata=0x0) at posix.c:800
#4202 0x00007f6218f7eab2 in posix_fstat (frame=0x7f621cde43bc, this=<optimized out>, fd=<optimized out>, xdata=<optimized out>) at posix.c:5856
#4203 0x00007f621f078266 in default_fstat (frame=0x7f621cde43bc, this=0x7f62140096e0, fd=0x7f621f2ed06c, xdata=0x0) at defaults.c:2618
#4204 0x00007f621f078266 in default_fstat (frame=0x7f621cde43bc, this=0x7f621400ae80, fd=0x7f621f2ed06c, xdata=0x0) at defaults.c:2618
#4205 0x00007f621f078266 in default_fstat (frame=0x7f621cde43bc, this=0x7f621400db00, fd=0x7f621f2ed06c, xdata=0x0) at defaults.c:2618
#4206 0x00007f6213bd09a4 in br_stub_fstat (frame=0x7f621cde43bc, this=0x7f621400f3a0, fd=0x7f621f2ed06c, xdata=0x0) at bit-rot-stub.c:2831
#4207 0x00007f621f078266 in default_fstat (frame=0x7f621cde43bc, this=0x7f6214010a10, fd=0x7f621f2ed06c, xdata=0x0) at defaults.c:2618
#4208 0x00007f6213797caa in pl_ftruncate (frame=0x7f621cde7990, this=0x7f6214011e20, fd=0x7f621f2ed06c, offset=<optimized out>, xdata=0x0) at posix.c:888
#4209 0x00007f621f078cde in default_ftruncate (frame=0x7f621cde7990, this=0x7f6214013250, fd=0x7f621f2ed06c, offset=1024000, xdata=0x0) at defaults.c:2801

#4210 0x00007f621337cad0 in ro_ftruncate (frame=0x7f621cde7990, this=0x7f62140147d0, fd=0x7f621f2ed06c, offset=1024000, xdata=0x0) at read-only-common.c:189
#4211 0x00007f621317046f in leases_ftruncate (frame=0x7f621cde7c0c, this=0x7f6214015d80, fd=0x7f621f2ed06c, offset=1024000, xdata=0x0) at leases.c:668
#4212 0x00007f6212f5a489 in up_ftruncate (frame=0x7f621cde7ce0, this=0x7f6214017250, fd=0x7f621f2ed06c, offset=1024000, xdata=0x0) at upcall.c:896
#4213 0x00007f621f093527 in default_ftruncate_resume (frame=0x7f621cde77e8, this=0x7f62140187e0, fd=0x7f621f2ed06c, offset=1024000, xdata=0x0) at defaults.c:2056
#4214 0x00007f621f0221d5 in call_resume (stub=0x7f621c635e9c) at call-stub.c:2508
#4215 0x00007f6212d47b1b in iot_worker (data=0x7f62140675d0) at io-threads.c:215
#4216 0x00007f621e786182 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#4217 0x00007f621e4b347d in clone () from /lib/x86_64-linux-gnu/libc.so.6
Comment 1 jiademing.dd 2016-08-23 08:03:44 UTC 
when truncate a large file, trash will read src and write dst, util the end of the file.However, the whole process is many recursive calls in the trash.so if the file is too large, too many recursive calls, will lead to stack overflow.
Comment 2 jiademing.dd 2016-08-23 08:09:50 UTC 
Can we use syncop instead of STACK_WIND to avoid recursive call?

Now when truncate a large file, trash will cost a lot of time(trash-max-filesize=1GB).
Comment 3 Jiffin 2016-08-30 12:22:26 UTC 
We cannot use syncop infra here. It is usually used in glusterfs client code path. Thanks for pointing out this issue. I will try to reproduce this issue and let you know
Comment 4 WuVT 2017-03-22 08:38:42 UTC 
(In reply to Jiffin from comment #3)
> We cannot use syncop infra here. It is usually used in glusterfs client code
> path. Thanks for pointing out this issue. I will try to reproduce this issue
> and let you know

Hi, Jiffin, I've met the same problem.
1) gluster volume set v1 features.trash on
2) gluster volume set v1 features.trash-max-filesize 1GB
3) mount -t glusterfs 127.0.0.1:v1 /mnt/test
4) dd if=/dev/zero of=/mnt/test/d1 bs=1M count=150
5) dd if=/dev/zero of=/mnt/test/d1 bs=1M count=150 (second time)
After the fifth step, glusterfsd went down.
I changed the stack size to unlimited, the problem still exists.
Here's some info:
[root@node12 7]# gluster v info v1
 
Volume Name: v1
Type: Distribute
Volume ID: 50429860-d368-49fe-aa8e-1b06a1ec5a44
Status: Started
Number of Bricks: 1
Transport-type: tcp
Bricks:
Brick1: node12:/data/2fe9ae62-3e0c-4f7f-be1d-d023732e4c36/v2/brick
Options Reconfigured:
features.trash-max-filesize: 1GB
diagnostics.brick-log-level: INFO
nfs.disable: on
user.smb: disable
auth.allow: node12,node13,,
performance.client-io-threads: on
performance.io-thread-count: 16
performance.write-behind: on
performance.flush-behind: on
performance.strict-o-direct: on
performance.write-behind-window-size: 32MB
performance.io-cache: on
performance.cache-size: 64MB
performance.cache-refresh-timeout: 1
features.trash: on
diagnostics.client-log-level: INFO

[root@node12 7]# ulimit -a
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 3878
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) unlimited
cpu time               (seconds, -t) unlimited
max user processes              (-u) 3878
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Is the any work around to avoid this problem, or any plan to solve this problem? Thanks!
Comment 5 Jiffin 2017-03-22 12:37:24 UTC 
(In reply to WuVT from comment #4)
> (In reply to Jiffin from comment #3)
> > We cannot use syncop infra here. It is usually used in glusterfs client code
> > path. Thanks for pointing out this issue. I will try to reproduce this issue
> > and let you know
> 
> Hi, Jiffin, I've met the same problem.
> 1) gluster volume set v1 features.trash on
> 2) gluster volume set v1 features.trash-max-filesize 1GB
> 3) mount -t glusterfs 127.0.0.1:v1 /mnt/test
> 4) dd if=/dev/zero of=/mnt/test/d1 bs=1M count=150
> 5) dd if=/dev/zero of=/mnt/test/d1 bs=1M count=150 (second time)
> After the fifth step, glusterfsd went down.
> I changed the stack size to unlimited, the problem still exists.
> Here's some info:
> [root@node12 7]# gluster v info v1
>  
> Volume Name: v1
> Type: Distribute
> Volume ID: 50429860-d368-49fe-aa8e-1b06a1ec5a44
> Status: Started
> Number of Bricks: 1
> Transport-type: tcp
> Bricks:
> Brick1: node12:/data/2fe9ae62-3e0c-4f7f-be1d-d023732e4c36/v2/brick
> Options Reconfigured:
> features.trash-max-filesize: 1GB
> diagnostics.brick-log-level: INFO
> nfs.disable: on
> user.smb: disable
> auth.allow: node12,node13,,
> performance.client-io-threads: on
> performance.io-thread-count: 16
> performance.write-behind: on
> performance.flush-behind: on
> performance.strict-o-direct: on
> performance.write-behind-window-size: 32MB
> performance.io-cache: on
> performance.cache-size: 64MB
> performance.cache-refresh-timeout: 1
> features.trash: on
> diagnostics.client-log-level: INFO
> 
> [root@node12 7]# ulimit -a
> core file size          (blocks, -c) unlimited
> data seg size           (kbytes, -d) unlimited
> scheduling priority             (-e) 0
> file size               (blocks, -f) unlimited
> pending signals                 (-i) 3878
> max locked memory       (kbytes, -l) 64
> max memory size         (kbytes, -m) unlimited
> open files                      (-n) 1024
> pipe size            (512 bytes, -p) 8
> POSIX message queues     (bytes, -q) 819200
> real-time priority              (-r) 0
> stack size              (kbytes, -s) unlimited
> cpu time               (seconds, -t) unlimited
> max user processes              (-u) 3878
> virtual memory          (kbytes, -v) unlimited
> file locks                      (-x) unlimited
> 
> Is the any work around to avoid this problem, or any plan to solve this
> problem? Thanks!

IMO the findings of jiademing.dd( iesool) is correct. It happens only if tries to truncate very large files(Till files of size 20M is fine).
Original solution requires lot of change in the code base.(may b target for 3.11).
As workaround I can sent a patch which won't stores files large than 10M to trash directory during truncate operation
Comment 6 WuVT 2017-03-23 01:50:23 UTC 
(In reply to Jiffin from comment #5)
> IMO the findings of jiademing.dd( iesool) is correct. It happens
> only if tries to truncate very large files(Till files of size 20M is fine).
> Original solution requires lot of change in the code base.(may b target for
> 3.11).
> As workaround I can sent a patch which won't stores files large than 10M to
> trash directory during truncate operation
In my production env, they would like to keep files in trash for a few days, and the size is from hundreds of MBs  to tens of GBs.
In the code of 3.7.20, the old file is copied to trash directory. Is it possible to implement trash truncate by calling posix_rename?
Comment 7 Jiffin 2017-03-23 12:06:44 UTC 
(In reply to WuVT from comment #6)
> (In reply to Jiffin from comment #5)
> > IMO the findings of jiademing.dd( iesool) is correct. It happens
> > only if tries to truncate very large files(Till files of size 20M is fine).
> > Original solution requires lot of change in the code base.(may b target for
> > 3.11).
> > As workaround I can sent a patch which won't stores files large than 10M to
> > trash directory during truncate operation
> In my production env, they would like to keep files in trash for a few days,
> and the size is from hundreds of MBs  to tens of GBs.
> In the code of 3.7.20, the old file is copied to trash directory. Is it
> possible to implement trash truncate by calling posix_rename?
Sorry I didn't get this. Incase of truncate we need to copy the old (original file) to trash directory before performing the truncate. so I don't understand how rename will helpful here?
 
The change which I am talking as work around will only effect truncated files. For the deleted files it will work based on the limit which have set(trash-max-file-size).
Comment 8 WuVT 2017-03-24 01:56:04 UTC 
(In reply to Jiffin from comment #7)
> Sorry I didn't get this. Incase of truncate we need to copy the old
> (original file) to trash directory before performing the truncate. so I
> don't understand how rename will helpful here?
>  
> The change which I am talking as work around will only effect truncated
> files. For the deleted files it will work based on the limit which have
> set(trash-max-file-size).

Sorry for my poor English.
I misunderstood the meaning of trash truncate. I need to learn the function of vfs->fops.
Another question, I tried to comment out truncate and ftruncate of trash-fops, like this:
struct xlator_fops fops = {
        .unlink          = trash_unlink,
        // .truncate        = trash_truncate,
        // .ftruncate       = trash_ftruncate,
        .rmdir           = trash_rmdir,
        .mkdir           = trash_mkdir,
        .rename          = trash_rename,
};
Is there any bad effects by doing this?
I tested the recycle of samba-4.2.3, it seems like that the recycle dosn't deal with truncated files.
Comment 9 Jiffin 2017-03-28 06:30:38 UTC 
(In reply to WuVT from comment #8)
> (In reply to Jiffin from comment #7)
> > Sorry I didn't get this. Incase of truncate we need to copy the old
> > (original file) to trash directory before performing the truncate. so I
> > don't understand how rename will helpful here?
> >  
> > The change which I am talking as work around will only effect truncated
> > files. For the deleted files it will work based on the limit which have
> > set(trash-max-file-size).
> 
> Sorry for my poor English.
> I misunderstood the meaning of trash truncate. I need to learn the function
> of vfs->fops.
> Another question, I tried to comment out truncate and ftruncate of
> trash-fops, like this:
> struct xlator_fops fops = {
>         .unlink          = trash_unlink,
>         // .truncate        = trash_truncate,
>         // .ftruncate       = trash_ftruncate,
>         .rmdir           = trash_rmdir,
>         .mkdir           = trash_mkdir,
>         .rename          = trash_rename,
> };
> Is there any bad effects by doing this?

It will disable for trash feature for truncate operations. If are u not worried about truncated files, then it is perfectly okay to do it.

> I tested the recycle of samba-4.2.3, it seems like that the recycle dosn't
> deal with truncated files.
Comment 10 Amar Tumballi 2019-05-09 20:07:05 UTC 
As there are work around which exists to get over the issue, would like to fix the issue later (if we get to it). For now, CLOSING with DEFERRED.
Note You need to log in before you can comment on or make changes to this bug.