[Bugs] [Bug 1335373] cyclic dentry loop in inode table

bugzilla at redhat.com bugzilla at redhat.com
Sat May 11 13:28:17 UTC 2019


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



--- Comment #12 from Raghavendra G <rgowdapp at redhat.com> ---
(In reply to Amar Tumballi from comment #10)
> Raghavendra, Yes, SDFS has performance impact. But the feature is still
> present and can be enabled if user's work load demands it.
> 
> My reasoning of closing this bug was mainly because for none of our users,
> this particular case was not hit (ie, there are no reports of it). So,
> focusing on that work when no one needs it is meaningless, that too when
> there are options available.

The second claim about no user has hit it is wrong. To repost the link I posted
in comment #8 - https://bugzilla.redhat.com/show_bug.cgi?id=1696353#c11. Also
I've found this scenario on SAS setups too -
https://bugzilla.redhat.com/show_bug.cgi?id=1581306#c47

I've already reasoned about non-feasibility of sdfs:
1. Its not available on client. There is no option which can load it in client
graphs. It can be loaded only on bricks. So, even if the user can accept perf
impact (which is highly unlikely, see point 2) the solution is not complete.
2. The commit I posted in comment #6 measured the impact of sdfs being loaded
on brick stack. We don't have any perf data to measure the impact if it gets
loaded on client graph. It's highly likely that perf impact is much greater
than the numbers posted in comment #6

All it takes to hit this bug is rename heavy workloads and there are many of
them as the following paradigm is pretty common while copying a file (rsync,
postgresql, SAS etc to give specific examples):
* create a tmp file
* write to it
* rename tmp file to actual file

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


More information about the Bugs mailing list