On 9/13/13 7:04 AM, Thavatchai Makphaibulchoke wrote: > On 09/12/2013 06:23 AM, Theodore Ts'o wrote: >> (I've trimmed the cc list to stop spamming people who probably don't >> care as much about this). >> >> So I've tried the following patch, and I've confirmed that for short >> xattrs (i.e., that fit inside the inode body, assuming an inode size > >> 128 bytes), the mbcache paths don't trigger at all. >> >> Could you try this patch and see if we can figure out why mbcache code >> paths are triggering for you? >> >> - Ted >> > > I tried the patch. First off, looks like the patch has a lot of warnings, it does produces tremendous non-stop warnings during aim7 run, particularly the one from line 1627. > > Unfortunately, looks like with this patch we are still calling ext4_xattr_cache_find(). All the patch does is issue warnings, so no fixing was expected ;) > I added more debugging code to print out the first few xattrs that get us into ex4_xattr_cache_find(). This is what I have, > > [ 80.540977] ext4_xattr_block_set: name len 28. > [ 155.480692] ext4_xattr_block_set: name selinux len 32. > [ 155.486531] ext4_xattr_block_set: name selinux len 32. > [ 155.492283] ext4_xattr_block_set: name selinux len 32. > [ 155.497988] ext4_xattr_block_set: name selinux len 32. > [ 155.504064] ext4_xattr_block_set: name selinux len 32. > [ 155.509771] ext4_xattr_block_set: name selinux len 32. > [ 155.515475] ext4_xattr_block_set: name selinux len 32. > [ 155.521179] ext4_xattr_block_set: name selinux len 32. ok, all small... > I'll continue debugging and get back with any new finding. suggestions: 1) send us dumpe2fs -h /dev/sdXX | grep "Inode size" for this filesystem 2) print out the inode number in your printk's above 3) stat one of those inodes in debugfs after the run (debugfs stat <inodenumber>) - with <> around the inode nr -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
