[Ocfs2-users] "ls" taking ages on a directory containing 900000 files

[Sunil Mushran]

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.francois at 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 at 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. ****
>
> ** **
>
> [image: Description : Description : Description :
> cid:image001.png at 01CD01F3.35091200]****
>
> * *
>
> *Amaury FRANCOIS*   •  *Ingénieur*****
>
> Mobile +33 (0)6 88  12 62 54****
>
> *amaury.francois at 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 ****
>
> [image: Description : test]****
>
> ** **
>
> ** **
>
> _______________________________________________
> Ocfs2-users mailing list
> Ocfs2-users at oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/ocfs2-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.oracle.com/pipermail/ocfs2-users/attachments/20121204/da625142/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 11516 bytes
Desc: not available
Url : http://oss.oracle.com/pipermail/ocfs2-users/attachments/20121204/da625142/attachment-0001.jpe 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 5635 bytes
Desc: not available
Url : http://oss.oracle.com/pipermail/ocfs2-users/attachments/20121204/da625142/attachment-0001.png