The strace looks like this (on all files) :
1354662591.755319 lstat64("TEW_STRESS_TEST_VM.1K_100P_10000F.P069_F01589.txt",
{st_mode=S_IFREG|0664, st_size=1000, ...}) = 0 <0.001389>
1354662591.756775 lstat64("TEW_STRESS_TEST_VM.1K_100P_10000F.P035_F01592.txt",
{st_mode=S_IFREG|0664, st_size=1000, ...}) = 0 <0.001532>
1354662591.758376 lstat64("TEW_STRESS_TEST_VM.1K_100P_10000F.P085_F01559.txt",
{st_mode=S_IFREG|0664, st_size=1000, ...}) = 0 <0.001429>
1354662591.759873 lstat64("TEW_STRESS_TEST_VM.1K_100P_10000F.P027_F01569.txt",
{st_mode=S_IFREG|0664, st_size=1000, ...}) = 0 <0.001377>
1354662591.761317 lstat64("TEW_STRESS_TEST_VM.1K_100P_10000F.P002_F01581.txt",
{st_mode=S_IFREG|0664, st_size=1000, ...}) = 0 <0.001420>
1354662591.762804 lstat64("TEW_STRESS_TEST_VM.1K_100P_10000F.P050_F01568.txt",
{st_mode=S_IFREG|0664, st_size=1000, ...}) = 0 <0.001345>
1354662591.764216 lstat64("TEW_STRESS_TEST_VM.1K_100P_10000F.P089_F01567.txt",
{st_mode=S_IFREG|0664, st_size=1000, ...}) = 0 <0.001541>
1354662591.765828 lstat64("TEW_STRESS_TEST_VM.1K_100P_10000F.P010_F01594.txt",
{st_mode=S_IFREG|0664, st_size=1000, ...}) = 0 <0.001358>
1354662591.767252 lstat64("TEW_STRESS_TEST_VM.1K_100P_10000F.P045_F01569.txt",
{st_mode=S_IFREG|0664, st_size=1000, ...}) = 0 <0.001396>
1354662591.768715 lstat64("TEW_STRESS_TEST_VM.1K_100P_10000F.P036_F01592.txt",
{st_mode=S_IFREG|0664, st_size=1000, ...}) = 0 <0.002072>
1354662591.770854 lstat64("TEW_STRESS_TEST_VM.1K_100P_10000F.P089_F01568.txt",
{st_mode=S_IFREG|0664, st_size=1000, ...}) = 0 <0.001722>
1354662591.772643 lstat64("TEW_STRESS_TEST_VM.1K_100P_10000F.P009_F01600.txt",
{st_mode=S_IFREG|0664, st_size=1000, ...}) = 0 <0.001281>
1354662591.773992 lstat64("TEW_STRESS_TEST_VM.1K_100P_10000F.P022_F01583.txt",
{st_mode=S_IFREG|0664, st_size=1000, ...}) = 0 <0.001413>We are using a 32 bits architecture, can it be the cause of the kernel not having enough memory ? Any possibility to change this behavior ? [Description : Description : Description : cid:image001.png@01CD01F3.35091200] Amaury FRANCOIS * Ingénieur Mobile +33 (0)6 88 12 62 54 amaury.franc...@digora.com<mailto:amaury.franc...@digora.com> Siège Social - 66 rue du Marché Gare - 67200 STRASBOURG Tél : 0 820 200 217 - +33 (0)3 88 10 49 20 [Description : test] De : Sunil Mushran [mailto:sunil.mush...@gmail.com] Envoyé : mardi 4 décembre 2012 18:29 À : Amaury Francois Cc : ocfs2-users@oss.oracle.com Objet : Re: [Ocfs2-users] "ls" taking ages on a directory containing 900000 files strace -p PID -ttt -T Attach and get some timings. The simplest guess is that the system lacks memory to cache all the inodes and thus has to hit disk (and more importantly take cluster locks) for the same inode repeatedly. The user guide has a section in NOTES explaining this. On Tue, Dec 4, 2012 at 8:54 AM, Amaury Francois <amaury.franc...@digora.com<mailto:amaury.franc...@digora.com>> wrote: Hello, We are running OCFS2 1.8 and on a kernel UEK2. An ls on a directory containing approx. 1 million of files is very long (1H). The features we have activated on the filesystem are the following : [root@pa-oca-app10 ~]# debugfs.ocfs2 -R "stats" /dev/sdb1 Revision: 0.90 Mount Count: 0 Max Mount Count: 20 State: 0 Errors: 0 Check Interval: 0 Last Check: Fri Nov 30 19:30:17 2012 Creator OS: 0 Feature Compat: 3 backup-super strict-journal-super Feature Incompat: 32592 sparse extended-slotmap inline-data metaecc xattr indexed-dirs refcount discontig-bg clusterinfo Tunefs Incomplete: 0 Feature RO compat: 1 unwritten Root Blknum: 5 System Dir Blknum: 6 First Cluster Group Blknum: 3 Block Size Bits: 12 Cluster Size Bits: 12 Max Node Slots: 8 Extended Attributes Inline Size: 256 Label: exchange2 UUID: 2375EAF4E4954C4ABB984BDE27AC93D5 Hash: 2880301520 (0xabade9d0) DX Seeds: 1678175851 1096448356 79406012 (0x6406ee6b 0x415a7964 0x04bba3bc) Cluster stack: o2cb Cluster name: appcluster Cluster flags: 1 Globalheartbeat Inode: 2 Mode: 00 Generation: 3567595533 (0xd4a5300d) FS Generation: 3567595533 (0xd4a5300d) CRC32: 0c996202 ECC: 0819 Type: Unknown Attr: 0x0 Flags: Valid System Superblock Dynamic Features: (0x0) User: 0 (root) Group: 0 (root) Size: 0 Links: 0 Clusters: 5242635 ctime: 0x508eac6b 0x0 -- Mon Oct 29 17:18:51.0 2012 atime: 0x0 0x0 -- Thu Jan 1 01:00:00.0 1970 mtime: 0x508eac6b 0x0 -- Mon Oct 29 17:18:51.0 2012 dtime: 0x0 -- Thu Jan 1 01:00:00 1970 Refcount Block: 0 Last Extblk: 0 Orphan Slot: 0 Sub Alloc Slot: Global Sub Alloc Bit: 65535 May inline-data or xattr be the source of the problem ? Thank you. [Description : Description : Description : cid:image001.png@01CD01F3.35091200] Amaury FRANCOIS * Ingénieur Mobile +33 (0)6 88 12 62 54<tel:%2B33%20%280%296%2088%C2%A0%2012%2062%2054> amaury.franc...@digora.com<mailto:amaury.franc...@digora.com> Siège Social - 66 rue du Marché Gare - 67200 STRASBOURG Tél : 0 820 200 217 - +33 (0)3 88 10 49 20<tel:%2B33%20%280%293%2088%2010%2049%2020> [Description : test] _______________________________________________ Ocfs2-users mailing list Ocfs2-users@oss.oracle.com<mailto:Ocfs2-users@oss.oracle.com> https://oss.oracle.com/mailman/listinfo/ocfs2-users
<<inline: image001.png>>
<<inline: image002.jpg>>
_______________________________________________ Ocfs2-users mailing list Ocfs2-users@oss.oracle.com https://oss.oracle.com/mailman/listinfo/ocfs2-users
