[Bugs] [Bug 1685023] New: FD processes for larger files are not closed soon after FOP finished

bugzilla at redhat.com bugzilla at redhat.com
Mon Mar 4 07:51:58 UTC 2019


            Bug ID: 1685023
           Summary: FD processes for larger files are not closed soon
                    after FOP finished
           Product: GlusterFS
           Version: mainline
            Status: NEW
         Component: bitrot
          Assignee: bugs at gluster.org
          Reporter: david.spisla at iternity.com
                CC: bugs at gluster.org
  Target Milestone: ---
    Classification: Community
      Docs Contact: bugs at gluster.org

Description of problem:
I did some observations concerning the bitrot daemon. It seems to be that the
bitrot signer is signing files depending on file size. I copied files with
different sizes into a volume and I was wonderung because the files get their
signature not the same time (I keep the expiry time default with 120). Here are
some examples:

300 KB file ~2-3 m 
70 MB file ~ 40 m 
115 MB file ~ 1 Sh
800 MB file ~ 4,5 h

There was already a bug from 2016:

I also figured out this discussion:
Kotresh mentioned there that the problem is because for some files, fd process
are still up in the brick process list. Bitrot signer can only sign a file if
the fd is closed. And according to my observations it seems to be that as
bigger a file is as longer the fd is still up. I could verify this with a
500MiB file and some smaller files. After a specific time only the fd for the
500MiB was up and the file still had no signature, for the smaller files there
were no fds and they already had a signature.

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

Gluster v5.3

Actual behaviour: 
The fd processes are still up for a specific time (maybe depend on file
size???) after FOP finished and bitd can't sign the file

Expected behaviour:
The fd processes should be closed soon after FOP finished so that bitd can sign
the file

You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
You are the Docs Contact for the bug.

More information about the Bugs mailing list