similar to: Slow performance

Looking in the archives I found a message from dominik.saar at 1und1.de on the 16/08/06, that is asking for a system to control the overquota warnings from within dovecot or dovecot LDA. The proposed solution is to use exim as MTA, since it has build in support. In my case I'm using postfix, what would be the recommended approach in that case? I was thinking of something like the cyrus LDA

Hello, I've been looking at ocfs2_rename() and I think there are two possible deadlocks: 1) ocfs2_double_lock() locks directories in the inode number order. But for a directory structure like: d1 / \ f1 d2 / f2 if you do 'mv f1 f2' and in parallel do something like 'rmdir d2' then ocfs2_double_lock() can try locking directories in order

Hi all, this patch set are the backport of inode alloc improvement from mainline to ocfs2-1.4. the patches are almost the same excpet one thing: Joel has added JBD2 support to ocfs2, so he has added "max_blocks" to alloc_context and add a new function "ocfs2_reserve_clusters_with_limit". We don't have that in ocfs2-1.4. So there are some great difference in patch 2.

In ocfs2, the inode block search looks for the "emptiest" inode group to allocate from. So if an inode alloc file has many equally (or almost equally) empty groups, new inodes will tend to get spread out amongst them, which in turn can put them all over the disk. This is undesirable because directory operations on conceptually "nearby" inodes force a large number of seeks. So

Changelog from V1 to V2: 1. Modify some codes according to Mark's advice. 2. Attach some test statistics in the commit log of patch 3 and in this e-mail also. See below. Hi all, In ocfs2, when we create a fresh file system and create inodes in it, they are contiguous and good for readdir+stat. While if we delete all the inodes and created again, the new inodes will get spread out and that

Please review the list of patches being applied to the ocfs2 1.4 tree. All patches list the mainline commit hash. Thanks Sunil

From: "Xiaowei.Hu" <xiaowei.hu at oracle.com> ocfs2_block_group_alloc_discontig() disables chain relink by setting ac->ac_allow_chain_relink = 0 because it grabs clusters from multiple cluster groups. It doesn't keep the credits for all chain relink,but ocfs2_claim_suballoc_bits overrides this in this call trace:

+cc: ocfs2-devel, sunil Marek, Thanks for the detailed report! Can I trouble you to file a bug at http://oss.oracle.com/bugzilla ... oh, is that your report http://oss.oracle.com/bugzilla/show_bug.cgi?id=1339? This looks like a deadlock of some sort. I don't think your hardware configuration really matters here. We'll keep looking into it. Joel On Tue, Dec 20, 2011 at 08:22:48AM

Hi, The following patches comprise the bulk of Ocfs2 updates for the 2.6.30 merge window. Aside from larger, more involved fixes, we're adding the following features, which I will describe in the order their patches are mailed. Sunil's exported some more state to our debugfs files, and consolidated some other aspects of our debugfs infrastructure. This will further aid us in debugging

The following series of patches comprises the bulk of our outstanding changes for Ocfs2. Aside from the usual set of cleanups and fixes that were inappropriate for 2.6.25, there are a few highlights: The '/sys/o2cb' directory has been moved to '/sys/fs/o2cb'. The new location meshes better with modern sysfs layout. A symbolic link has been placed in the old location so as to

ocfs2 currently uses the Journaled Block Device (JBD) for its journaling. This is a very stable and tested codebase. However, JBD is limited by architecture to 32bit block numbers. This means an ocfs2 filesystem is limited to 2^32 blocks. With a 4K blocksize, that's 16TB. People want larger volumes. Fortunately, there is now JBD2. JBD2 adds 64bit block number support and some other