similar to: [PATCH] ocfs2: Use xs->bucket to set xattr value outside.

Hi all, So I have finally finished the v1 of reflink for ocfs2. It has some bugs that I am still investigating, but the schema is almost there. So I'd like to send it out first for review. And Tristan and I will continue to work on the stability of the code. The general information for reflink, please see http://oss.oracle.com/osswiki/OCFS2/DesignDocs/Reflink. For the design doc, please

Hi all, Change from v1 to v2: bug fix and metadata/credits reservation improvement. The general information for reflink, please see http://oss.oracle.com/osswiki/OCFS2/DesignDocs/Reflink. For the design doc, please see http://oss.oracle.com/osswiki/OCFS2/DesignDocs/RefcountTrees http://oss.oracle.com/osswiki/OCFS2/DesignDocs/ReflinkOperation

When the extended attribute namespace grows to a b-tree, the leaf clusters are organized by means of 'buckets'. Each bucket is 4K in size, regardless of blocksize. Thus, a bucket may be made of more than one block. fs/ocfs2/xattr.c has a nice little abstraction to wrap this, struct ocfs2_xattr_bucket. It contains a list of buffer_heads representing these blocks, and there is even an

Hi all, So I have finally finished the v3 of reflink for ocfs2. The biggest change is that we support 64bit cluster offset now(Thank Mark and Joel for it). [View] http://oss.oracle.com/git/?p=tma/linux-2.6.git;a=shortlog;h=refcount [Pull] git://oss.oracle.com/git/tma/linux-2.6.git refcount The general information for reflink, please see http://oss.oracle.com/osswiki/OCFS2/DesignDocs/Reflink.

Hi, gcc 4.4.1 generates the following build warning on i386: CC [M] fs/ocfs2/xattr.o fs/ocfs2/xattr.c: In function ???ocfs2_xattr_block_get???: fs/ocfs2/xattr.c:1055: warning: ???block_off??? may be used uninitialized in this function The following fix is based on a similar approach by David Howells few days back: http://lkml.org/lkml/2009/7/9/109, Signed-off-by: Subrata Modak<subrata at

Hi, This is the second batch of Ocfs2 patches intended for the merge window. The 1st batch were sent out previously: http://lkml.org/lkml/2008/12/19/280 The bulk of this set is comprised of Jan Kara's patches to add quota support to Ocfs2. Many of the quota patches are to generic code, which I carried to make merging of the Ocfs2 support easier. All of the non-ocfs2 patches should have

Hi, For EAs data structure in inode/block are little different from them in bucket. These two patches try to make them same for the most part. The first patch set xh_free_start and xh_name_value_len when EAs in inode/block. xh_free_start is useful to keep the minimum offset of the xattr name/value. But xh_name_value_len is not very useful because we don't have "hole" when EAs in

Hi, I have fixed the problems in version 1 patches. These two patches based on the latest main line kernel. Thanks, tiger > For EAs data structure in inode/block are little different from them in > bucket. These two patches try to make them same for the most part. > > The first patch set xh_free_start and xh_name_value_len when EAs in > inode/block. xh_free_start is useful to

Check if some pointers are not NULL due to read errors or other problems Signed-off-by: Frediano Ziglio <frediano.ziglio at citrix.com> --- core/fs/ext2/ext2.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/core/fs/ext2/ext2.c b/core/fs/ext2/ext2.c index bddde8d..8f0f2a4 100644 --- a/core/fs/ext2/ext2.c +++ b/core/fs/ext2/ext2.c @@ -139,6 +139,8 @@

Modification from V2 to V3: Use a more pefect code suggested by Joel. Thank Joel for it. In ocfs2/xattr, we must make sure the xattrs which have the same hash value exist in the same bucket so that the search schema can work. But in the old implementation, when we want to extend a bucket, we just move half number of xattrs to the new bucket. This works in most cases, but if we are lucky enough we

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

From: Raphael S. Carvalho <raphael.scarv at gmail.com> Wrote the documentation below. I think it would be good to push the doc to the wiki as soon as the UFS support gets merged. Unix Fast File System (UFS/FFS) 1/2 on Syslinux - (usage/install) ----- There is a confusion about the name of this file system, then I decided to contact the author who replied: "The name has always been

From: Raphael S. Carvalho <raphael.scarv at gmail.com> Change since v1: * Fix bug on dentry structure (thank you specification; btw, sarcasm), and consequently a bug on ufs_readdir. * Add readlink support (applied tests for symlinks whose destionation path were stored in blk pointers and the file itself). * Several improvements. Wrote the documentation below. I think it would be good to

Hi Mark, This is the fix for 2.6.29(introduced by uniting the bucket journal access). Since I found no fixes-for-2.6.29 in your ocfs2.git, it is based on your original upstream-linus. In ocfs2_xattr_value_truncate, we may call b-tree codes which will extend the journal transaction. It has a potential problem that it may let the already-accessed-but-not-dirtied buffers gone. So we'd better

From: Raphael S. Carvalho <raphael.scarv at gmail.com> It's already loading modules successfully, booting Linux, and both UFS version 1 and 2 seem to be working correctly. Signed-off-by: Raphael S. Carvalho <raphael.scarv at gmail.com> --- core/fs/ufs/bmap.c | 202 ++++++++++++++++++++++++++ core/fs/ufs/ufs.c | 404 ++++++++++++++++++++++++++++++++++++++++++++++++++++

It's already loading modules successfully, and both UFS version 1 and 2 seems to be working correctly. Special thanks to Paulo Alcantara and Matt Fleming for being always ready to help me and give feedback. Signed-off-by: Raphael S.Carvalho <raphael.scarv at gmail.com> --- core/fs/ufs/bmap.c | 202 ++++++++++++++++++++++++++ core/fs/ufs/ufs.c | 404

Hi, This branch contains the new ext4's inline data support which has been added recently to kernel 3.8. In addition to inline data support, there are other patches that remove trainling whitespaces and extra new lines in ext2fs code and the other adds an assert() macro to Syslinux core. I think it's worth mentioning that these changes were made against master branch.

Currently, when listing xattrs, kernel define XATTR_LIST_MAX as 65536 in include/linux/limits.h, so it can't handle too many xattrs. But with ocfs2 xattr tree, we actually have no limit for the number. And it will pollute the message with something like this when listing. (27738,0):ocfs2_iterate_xattr_buckets:3158 ERROR: status = -34 (27738,0):ocfs2_xattr_tree_list_index_block:3264 ERROR:

The following series of patches attempts to detach metadata I/O from struct inode. They are currently tied together pretty tightly. Metadata reads happen via the ocfs2_read_blocks() functions, writes via both jbd2 and ocfs2_write_blocks(). - Each inode has a cache of associated metadata blocks stored on its ip_metadata_cache member. The ocfs2_read/write_blocks() functions take a struct