Hi,
I have changed the i_version_hi field to a le32 and also cleaned up the
whitespace.
This patch adds a 32-bit i_version_hi field to ext4_inode, which can be used
for 64-bit inode versions.
Signed-off-by: Andreas Dilger [EMAIL PROTECTED]
Signed-off-by: Kalpak Shah [EMAIL PROTECTED]
Index:
From: Aneesh Kumar K.V [EMAIL PROTECTED]
The code is derived out of the latest ext4 kernel source. I
have tried to keep the code as close as possible to the kernel
sources. This makes sure that any fixes for the tree building
code in kernel should be easily applied to ext4migrate. The
ext3_ext
From: Aneesh Kumar K.V [EMAIL PROTECTED]
Add ext4migrate utility that helps in migrating a ext3 block mapped
inode to ext4 extent mapped inode.
ext4migrate command takes the below syntax
ext4migrate [--display | --migrate ] image_name filename
The --display option helps in displaying the block
On jeu, 2007-03-29 at 13:59 -0600, Andreas Dilger wrote:
On Mar 29, 2007 14:17 +0200, Vincent Caron wrote:
I just noticed that 'tune2fs -l' did not returned a lively updated
information regarding the free inodes count (looks like it's always
correct after unmounting).
This is a bit of
On Mar 31, 2007 10:39 -0400, Theodore Tso wrote:
I'm going to let this one soak for a bit to make sure we don't pick up
any fase positives or negatives in the hueristics.
@@ -133,11 +133,10 @@ int e2fsck_pass1_check_device_inode(ext2
+ * If the index flag is set, then this is a bogus
On Tue, Apr 03, 2007 at 11:37:16AM -0600, Andreas Dilger wrote:
On Mar 31, 2007 10:39 -0400, Theodore Tso wrote:
I'm going to let this one soak for a bit to make sure we don't pick up
any fase positives or negatives in the hueristics.
@@ -133,11 +133,10 @@ int
On Apr 03, 2007 15:37 +0530, Aneesh Kumar K.V wrote:
The extent insert code is derived out of the latest ext4 kernel
source. I have tried to keep the code as close as possible to the
kernel sources. This makes sure that any fixes for the tree building
code in kernel should be easily applied
This patch also seems to make sense for 2.6.16, or do I miss anything?
TIA
Adrian
commit f58a74dca88d48b0669609b4957f3dd757bdc898
Author: Eric Sandeen [EMAIL PROTECTED]
Date: Sat Oct 28 10:38:27 2006 -0700
[PATCH] jbd: journal_dirty_data re-check for unmapped buffers
When
On Apr 03, 2007 15:55 +0200, Vincent Caron wrote:
BTW, if ondisk superblocks are not updated until specific events occur
(umount, statfs), what is the consequence of a system crash ? Does
journalization come into play (superblock=metadata?), does fsck fixes
figures from other ondisk
