Amaury Francois
2012-Dec-04 16:54 UTC
[Ocfs2-users] "ls" taking ages on a directory containing 900000 files
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.
[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<mailto: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
[Description?: test]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://oss.oracle.com/pipermail/ocfs2-users/attachments/20121204/b4eec0ea/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5635 bytes
Desc: image001.png
Url :
http://oss.oracle.com/pipermail/ocfs2-users/attachments/20121204/b4eec0ea/attachment-0001.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 11516 bytes
Desc: image002.jpg
Url :
http://oss.oracle.com/pipermail/ocfs2-users/attachments/20121204/b4eec0ea/attachment-0001.jpg
Sunil Mushran
2012-Dec-04 17:28 UTC
[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.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