[Bugs] [Bug 1751722] Gluster fuse mount crashed during truncate

bugzilla at redhat.com bugzilla at redhat.com
Wed Sep 18 15:55:59 UTC 2019


--- Comment #5 from Krutika Dhananjay <kdhananj at redhat.com> ---
The size going negative is when two consecutive truncates on the
__DIRECT_IO_TEST__ file (coming from open with O_TRUNC) happened in the
following sequence:

1. Size of the file at the beginning - 512b
2. First truncate on a given mount truncated the file to size 0. Delta size =
final size - initial size = 0 - 512 = -512.
3. Xattrop is now sent with -512. And file size had been 512. So 512 + (-512) =
0. Final on-disk size at the end of this truncate is 0.
But shard translator in the truncate fop callback continues to cache 512 as the
file size.
4. Then a second truncate (again to size 0) is sent, without a lookup or stat
preceding it. So the size in cache is believed to be true.
Delta size = final size - initial size = 0 - 512 = -512. (here initial size
should have been 0 but it is wrongly assumed to be 512).
So an xattrop is sent with -512. So 0 - 512 = 0xfffffffffffffe00

And this is what we see in the getfattr output of the file:

[root at rhsqa-grafton8 ~]# getfattr -d -m . -e hex
getfattr: Removing leading '/' from absolute path names
# file: gluster_bricks/data/data/__DIRECT_IO_TEST__

More evidence in wireshark output. Will paste it here tomorrow for the sake of
completeness (my laptop's freezing at some point when i try to load the pcap
file which is huge in wireshark)


Part of the reason why we hit this crash now is because truncate codepath in
shard had largely remained untested. With the newly introduced block-size
detection code in rhv/ovirt, which primarily opens the file __DIRECT_IO_TEST__
with O_TRUNC and performs io on it, the truncate fop path is now getting
exercised frequently.


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

More information about the Bugs mailing list