lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <5239B65E.4060202@redhat.com> Date: Wed, 18 Sep 2013 09:19:10 -0500 From: Eric Sandeen <sandeen@...hat.com> To: Thavatchai Makphaibulchoke <thavatchai.makpahibulchoke@...com> CC: "Theodore Ts'o" <tytso@....edu>, Andreas Dilger <adilger@...ger.ca>, T Makphaibulchoke <tmac@...com>, "linux-ext4@...r.kernel.org List" <linux-ext4@...r.kernel.org>, aswin@...com, aswin_proj@...ts.hp.com Subject: Re: [PATCH v3 0/2] ext4: increase mbcache scalability On 9/17/13 11:43 AM, Thavatchai Makphaibulchoke wrote: > On 09/13/2013 12:59 PM, Eric Sandeen wrote: >> >> 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 >> > > I think I found out why we get into the mbcache path. The test uses > ramfss, which are mounted and unmounted at the start and end of the > test. Looks like a ramfs' default inode size is 128, causing all the > mbcaching for the xattrs. There seems to be nothing wrong with > either SELinux or xattr. Sorry for the confusion. smaller filesystems go back to 128 byte inodes, IIRC. That's why I asked for dumpe2fs long ago ;) But glad to have the mystery solved! Thanks, -Eric > Thanks, Mak. > -- 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