[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bug-107301-13602-wfM2NtuuTF@https.bugzilla.kernel.org/>
Date: Mon, 09 Nov 2015 08:50:58 +0000
From: bugzilla-daemon@...zilla.kernel.org
To: linux-ext4@...r.kernel.org
Subject: [Bug 107301] system hang during ext4 xattr operation
https://bugzilla.kernel.org/show_bug.cgi?id=107301
--- Comment #7 from Jan Kara <jack@...e.cz> ---
Yeah, that would test what the performance would look like without mbcache.
BTW: Among xattrs ceph is using how many of them are the same? Mbcache is a win
for the common case where xattrs are mostly used for ACLs or SE Linux labels
and thus the reuse is big (mbcache is essentially a deduplication layer for
xattrs).
And yes, it is in a need of some updates to meet current scalability demands (I
don't think what you hit is a bug as such, rather an inefficiency that becomes
lethal at your scale) - other users than ceph occasionally report issues as
well. Probably we should track things per-fs, not globally, hook each per-fs
mbcache into the shrinker framework and don't introduce artificial upper bounds
on the number of entries and instead let natural memory pressure deal with it.
For now I'm not convinced adding a mount option to disable mbcache is the right
way to go. Rather we should make it lightweight enough that it doesn't add too
much overhead for the cases where it is not needed. With the mount option there
is always the trouble that someone has to know it to turn it on/off and
sometimes there even isn't a good choice as you can have heavy xattr reuse for
some inodes and also quite a few unique xattrs for other inodes...
--
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists