From: bugzilla-daemon@bugzilla.kernel.org
To: linux-ext4@vger.kernel.org
Subject: [Bug 107301] system hang during ext4 xattr operation
Date: Thu, 19 Nov 2015 15:11:22 +0000 [thread overview]
Message-ID: <bug-107301-13602-QVztKvQIpk@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-107301-13602@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=107301
--- Comment #20 from Theodore Tso <tytso@mit.edu> ---
Apologies for not responding right away. I'm currently on vacation.
So this also means that if someone sends me a patch right away, I'm
not likely to have time to look at it for a week or two.
As far as trying to make mbcache more scalable, this would be great,
but I suspect it's not going to be very easy because it requires a
global data structure, which is fundamentally hard to scale. I can
imagine some schemes that sacrifice some of mbcache's ability to spot
duplicate xattr sets --- for example, you could just use a trylock,
and if there is lock contention just give up on detecting duplicate
xattrs.
Or maybe we could use some hueristics based on the xattr type/key to
decide whether using mbcache is likely to be successful. So if we
know that Posix ACL's are very likely to be shared, and ceph xattrs
are very unlikely to be shared, this could be used to decide whether
or not to use mbcache automatically, without requiring a mount option.
Even better would be one where for unknonw xattr type/key
combinations, we use some learning algorithm which determines after
using mbcache for N instances of that xattr, if the percentage of
cache hits is too low, we stop using mbcache for that type/key
combination.
--
You are receiving this mail because:
You are watching the assignee of the bug.
next prev parent reply other threads:[~2015-11-19 15:11 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-05 13:54 [Bug 107301] New: system hang during ext4 xattr operation bugzilla-daemon
2015-11-05 15:45 ` [Bug 107301] " bugzilla-daemon
2015-11-05 17:02 ` bugzilla-daemon
2015-11-05 17:41 ` bugzilla-daemon
2015-11-06 2:43 ` bugzilla-daemon
2015-11-06 20:29 ` bugzilla-daemon
2015-11-07 15:24 ` bugzilla-daemon
2015-11-07 17:58 ` bugzilla-daemon
2015-11-09 8:50 ` bugzilla-daemon
2015-11-09 9:24 ` bugzilla-daemon
2015-11-09 10:11 ` bugzilla-daemon
2015-11-09 14:31 ` bugzilla-daemon
2015-11-09 15:22 ` bugzilla-daemon
2015-11-09 18:13 ` bugzilla-daemon
2015-11-10 11:16 ` bugzilla-daemon
2015-11-11 2:37 ` bugzilla-daemon
2015-11-11 10:28 ` bugzilla-daemon
2015-11-11 11:37 ` bugzilla-daemon
2015-11-11 14:53 ` bugzilla-daemon
2015-11-18 20:48 ` bugzilla-daemon
2015-11-19 0:49 ` bugzilla-daemon
2015-11-19 15:11 ` bugzilla-daemon [this message]
2015-12-10 2:51 ` bugzilla-daemon
2015-12-10 16:51 ` bugzilla-daemon
2016-03-31 13:53 ` bugzilla-daemon
2016-04-08 10:09 ` bugzilla-daemon
2016-04-08 20:46 ` bugzilla-daemon
2016-04-12 12:52 ` bugzilla-daemon
2016-04-13 9:07 ` bugzilla-daemon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-107301-13602-QVztKvQIpk@https.bugzilla.kernel.org/ \
--to=bugzilla-daemon@bugzilla.kernel.org \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox