[Bugs] [Bug 1369349] enable trash, then truncate a large file lead to glusterfsd segfault

bugzilla at redhat.com bugzilla at redhat.com
Thu Mar 23 12:06:44 UTC 2017


https://bugzilla.redhat.com/show_bug.cgi?id=1369349



--- Comment #7 from Jiffin <jthottan at redhat.com> ---
(In reply to WuVT from comment #6)
> (In reply to Jiffin from comment #5)
> > IMO the findings of jiademing.dd( iesool at 126.com) 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).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=AYkDajeFC0&a=cc_unsubscribe


More information about the Bugs mailing list