similar to: a patch for ocfs2_link

The following patches implement indexed directory support in Ocfs2, mostly according to the design doc I wrote up a while ago: http://oss.oracle.com/osswiki/OCFS2/DesignDocs/IndexedDirectories The patches have been rebased on top of 2.6.29-rc2. It should be trivial to put them into merge_window. Things are what I'd call complete now. I'd like to get these into the merge_window branch

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

nlink should be also checked in ocfs2_inode_revalidate(). before setting flag OCFS2_INODE_DELETED ip_flags (between unlink and delete vote), the nlink may be 0. the patch is against 1.4 git. 1.2 svn should has the same patch with different line number. Signed-off-by: Wengang wang <wen.gang.wang at oracle.com> -- diff --git a/fs/ocfs2/inode.c b/fs/ocfs2/inode.c index 591e693..6b5a83e

While adding a file into orphan dir in ocfs2_orphan_add(), it calls __ocfs2_add_entry() before ocfs2_journal_access_di(). If ocfs2_journal_access_di() failed, the file is added into orphan dir, and orphan dir dinode updated, but file dinode has not been updated. Accordingly, the data is not consistent between file dinode and orphan dir. So, need to call ocfs2_journal_access_di() before

Hi all, I have 2 servers connected between 10gig fiber network (dedicated for only ocfs2 cluster). My disks on the FC storage. There is no any error msg at the storage side but I sometimes get the "ocfs2_check_dir_for_entry:2119 ERROR: status = -17" error. Some example lines below: Dec 7 23:08:03 www1 kernel: [15383.267996] (imap,*20060*,0):ocfs2_check_dir_for_entry:2119 ERROR:

Hi Linus, Here are some 2.6.20 fixes for ocfs2. The patch by Zhen Wei isn't really a fix, but a very small amount of support for a feature which is mostly implemented in ocfs2-tools. Considering it's just a single attribute export via configfs, I'd say it's pretty safe to merge. Please pull from 'upstream-linus' branch of

We do log replay in a single transaction, so it''s not good to do unbound operations during replaying log. This patch makes orphan inodes cleanup executed after replaying log. It also avoid doing other unbound operations such as truncating a file during replaying log. These unbound operations are postponed to the orphan inode cleanup stage. Signed-off-by: Yan Zheng

In fixing how we deal with bad inodes, we had a regression in the orphan cleanup code, since it expects to get a bad inode back. So fix it to deal with getting -ESTALE back by deleting the orphan item manually and moving on. Thanks, Reported-by: Simon Kirby <sim@hostway.ca> Signed-off-by: Josef Bacik <josef@redhat.com> --- fs/btrfs/inode.c | 36

Hi, I've been playing lately with lockdep annotations of OCFS2. I seem to have most of the false positives sorted out and currently I hit the report below. I've analyzed that ocfs2_extend_dir() does first lock local alloc inode in ocfs2_reserve_clusters() and then acquires ip_alloc_sem from the directory. The usual ordering e.g. in ocfs2_write_begin() is to first acquire ip_alloc_sem

we need do more checking for validation in ocfs2_get_dentry(). 1) OCFS2_INODE_DELETED flag 2) i_nlink the patch is against 1.4 git. Signed-off-by: Wengang wang <wen.gang.wang at oracle.com> -- diff --git a/fs/ocfs2/export.c b/fs/ocfs2/export.c index 649f3c8..36ccf27 100644 --- a/fs/ocfs2/export.c +++ b/fs/ocfs2/export.c @@ -49,6 +49,7 @@ static struct dentry *ocfs2_get_dentry(struct

The inode eviction can be very slow, because during eviction we tell the VFS to truncate all of the inode''s pages. This results in calls to btrfs_invalidatepage() which in turn does calls to lock_extent_bits() and clear_extent_bit(). These calls result in too many merges and splits of extent_state structures, which consume a lot of time and cpu when the inode has many pages. In some

Found 15 patches (out of 162) that appeared relevant to ocfs2 1.4. Please review. Sunil

Hi, We have encountered another funny with ext3 on 2.4. Like the kernel NFS server, we have a routine in InterMezzo that does something like looking up an inode by inode number. (compare intermezzo's presto_ilookup or knfsd's nfsfh_iget) Effectively both of these routines do ilookup() { inode = iget(sb, ino) if (inode->i_nlink==0) iput(inode); .... } We find that

Linux kernel (as of 2.6.15.4) has the following performance bug: Syncing (fsync() or fdatasync()) files with zero links (deleted files) in not no-op, as it should be. See details, a test C program, and the rationale in the URL below: http://b2e.ex-code.com/index.php/soft/2006/02/24/linux_performance_bug_zero_links_fsync In the article with the URL above it is also explained how to make much

Generally, orphan scan run in ocfs2_wq and is used to replay orphan dir. So for some low end iscsi device, the delete_inode may take a long time(In some devices, I have seen that delete 500 files will take about 15 secs). This will eventually cause umount to livelock(umount has to flush ocfs2_wq which will wait until orphan scan to finish). So this patch just try to finish the orphan scan

Hi, we use attachment dedup with lots of emails (still migrating to it from maildir). We use netapp storage with wafl filesystem over nfs. Problem is that netapp has hard limit of 100k hardlinks to one file. And we encountered it. Problem is that dovecot start do segfault (lmtp,dsync,pop3 etc) when it happend when tried to deliver new emails with that attachment. Here is strace of dsync: 6740

Hi, I'm having a problem using --link-dest and --hard-links when the fs hits the hard link limit (link(2) returns EMLINK). Using rsync 3.0.7 an error is thrown and the target file is not created. Glancing at git head it _looks_ like things could now be a little nicer. Perhaps the target file is copied instead of hard linked when hardlinking fails -- I've not tested it. Anyway, the

https://bugzilla.netfilter.org/show_bug.cgi?id=1459 Bug ID: 1459 Summary: EMLINK error for NFT_GOTO Product: nftables Version: unspecified Hardware: x86_64 OS: All Status: NEW Severity: enhancement Priority: P5 Component: kernel Assignee: pablo at netfilter.org

Hello, Over the last month or so, I've noticed the following error showing up repeatedly in my system logs under kernel 2.4.18-ac3 and more recently under 2.4.19-rc1: EXT3-fs error (device ide0(3,3)) in ext3_new_inode: error 28 I've now been able to capture the following Oops before the system went down entirely: Assertion failure in do_get_write_access() at transaction.c:611:

Hello, the following series of patches fixes some issues with OCFS2 quotas. The first patch modifies VFS quota locking, the next patch uses the fact to simplify OCFS2 quota locking and solves a few deadlock issues. The third and the fourth patches fix another possible deadlocks in OCFS2 quota code and the last patch is a minor cleanup. Honza