Get loan from xaio loan company........Apply now!!!
- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] ext4 update
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git for_linus To get a number of ext4 bug fixes for 2.6.25. Thanks, - Ted Akinobu Mita (1): ext4: add missing ext4_journal_stop() Andi Kleen (1): Remove incorrect BKL comments in ext4 Aneesh Kumar K.V (8): ext4: Fix locking hierarchy violation in ext4_fallocate() ext4: Don't leave behind a half-created inode if ext4_mkdir() fails ext4: Fix memory and buffer head leak in callers to ext4_ext_find_extent() ext4: Get journal write access before modifying the extent tree ext4: Don't claim block from group which has corrupt bitmap ext4: Don't mark filesystem error if fallocate fails ext4: set EXT4_EXTENTS_FL only for directory and regular files ext4: ext4_find_next_zero_bit needs an aligned address on some arch Mingming Cao (1): ext4: Fix BUG when writing to an unitialized extent Theodore Ts'o (1): ext4: Don't use ext4_dec_count() if not needed Valerie Clement (2): ext4: Fix kernel BUG at fs/ext4/mballoc.c:910! ext4: modify block allocation algorithm for the last group fs/ext4/dir.c |2 +- fs/ext4/extents.c | 59 +++- fs/ext4/ialloc.c| 22 +++--- fs/ext4/inode.c | 56 +-- fs/ext4/mballoc.c | 80 +++ fs/ext4/migrate.c |5 ++ fs/ext4/namei.c | 18 +++- fs/ext4/resize.c|1 + include/linux/ext4_fs_extents.h |1 + 9 files changed, 177 insertions(+), 67 deletions(-) - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in e2fsprogs.git (topics)
On Mon, Feb 25, 2008 at 11:32:34AM -0600, Eric Sandeen wrote: > Are you sure? This was her patch comment, from > [PATCH] ext4: Don't set EXTENTS_FL flag for fast symlinks: You're right, I confused myself. > > But you do raise a good point that we need to support using the > > extents format in order to support blocks > 2**32, so we can't just > > arbitrary convert all symlinks to the old-style direct block maps. > > ... so I think we really *should* be unconditionally storing *long* > symlinks in extent format, on ext4... right? Yes, I think so. Being liberal in what you receive is probably a good idea, but we should only store new symlinks in one standard format, and the extents format makes sense since it will allow us to support 48-bit block numbers. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in e2fsprogs.git (topics)
Theodore Tso wrote: > On Sun, Feb 24, 2008 at 09:20:50PM -0700, Andreas Dilger wrote: >> On Feb 22, 2008 19:15 -0500, Theodore Ts'o wrote: >>> So before the recent patch were we actually creating long symlinks in >>> extents format? Or were we just setting the flag but still treating >>> them as a block number? If it was the latter, I guess we can put in >>> code into e2fsck to detect that case, and convert it back to a >>> singleton block number. >> Eric informed me that the long symlinks were actually stored in extent >> mapped blocks. That is not harmful, because it can only be a single >> block and it will always fit into the inode. The other thing to note >> is that extent mapping is REQUIRED for > 32-bit blocknumbers, so we >> may as well fix e2fsprogs to allow these symlinks to be handled normally. > > Well, at least some kernel versions (as of sometime just before > 2.6.25, iirc) were storing the long symlink as a single block in > i_block[0], despite EXTENTS_FL being set. Valerie noticed this, and I > confirmed it, as it caused the mainline e2fsck extents support to core > dump. Basically, what this means is that e2fsprogs can't trust > EXTENTS_FL for long symlinks. Are you sure? This was her patch comment, from [PATCH] ext4: Don't set EXTENTS_FL flag for fast symlinks: > For fast symbolic links, the file content is stored in the i_block[] > array, which is not compatible with the new file extents format. > e2fsck reports error on such files because EXTENTS_FL is set. > Don't set the EXTENTS_FL flag when creating fast symlinks. so this was for *fast* symlinks, stored internally on top of the i_block array, right? In that case trying to read it as extents would certainly cause problems. But, for *long* symlinks I think they truly were stored in extent format, and as you say... > But you do raise a good point that we need to support using the > extents format in order to support blocks > 2**32, so we can't just > arbitrary convert all symlinks to the old-style direct block maps. ... so I think we really *should* be unconditionally storing *long* symlinks in extent format, on ext4... right? -Eric - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in e2fsprogs.git (topics)
On Mon, Feb 25, 2008 at 10:13:39AM -0500, Theodore Tso wrote:
> On Sun, Feb 24, 2008 at 09:20:50PM -0700, Andreas Dilger wrote:
> > On Feb 22, 2008 19:15 -0500, Theodore Ts'o wrote:
> > > So before the recent patch were we actually creating long symlinks in
> > > extents format? Or were we just setting the flag but still treating
> > > them as a block number? If it was the latter, I guess we can put in
> > > code into e2fsck to detect that case, and convert it back to a
> > > singleton block number.
> >
> > Eric informed me that the long symlinks were actually stored in extent
> > mapped blocks. That is not harmful, because it can only be a single
> > block and it will always fit into the inode. The other thing to note
> > is that extent mapping is REQUIRED for > 32-bit blocknumbers, so we
> > may as well fix e2fsprogs to allow these symlinks to be handled normally.
>
> Well, at least some kernel versions (as of sometime just before
> 2.6.25, iirc) were storing the long symlink as a single block in
> i_block[0], despite EXTENTS_FL being set. Valerie noticed this, and I
> confirmed it, as it caused the mainline e2fsck extents support to core
> dump. Basically, what this means is that e2fsprogs can't trust
> EXTENTS_FL for long symlinks.
>
> But you do raise a good point that we need to support using the
> extents format in order to support blocks > 2**32, so we can't just
> arbitrary convert all symlinks to the old-style direct block maps.
How about the patch like below on top of the patch queue. Patch queue
currently enable extent flag only for directory and file . This patch
add it to normal symlink. With this fast symlink still have the extent
format enabled. I guess this would need a patch to the interim branch of
e2fsprogs to allow normal symlink to have extent format.
-aneesh
ext4: Enable extent format for symlink.
From: Aneesh Kumar K.V <[EMAIL PROTECTED]>
This patch enable extent format for normal symlink. Extent format enables
to refere file system blocks > 32 bits. Enabling extent format for symlink
enables to have symlink block beyond 2**32 blocks. We still don't enable
extent format for fast symlink.
Signed-off-by: Aneesh Kumar K.V <[EMAIL PROTECTED]>
---
fs/ext4/ialloc.c |4 ++--
fs/ext4/namei.c |2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
index 78d1094..1462189 100644
--- a/fs/ext4/ialloc.c
+++ b/fs/ext4/ialloc.c
@@ -842,8 +842,8 @@ got:
goto fail_free_drop;
}
if (test_opt(sb, EXTENTS)) {
- /* set extent flag only for diretory and file */
- if (S_ISDIR(mode) || S_ISREG(mode)) {
+ /* set extent flag only for diretory, file and normal symlink*/
+ if (S_ISDIR(mode) || S_ISREG(mode) || S_ISLNK(mode)) {
EXT4_I(inode)->i_flags |= EXT4_EXTENTS_FL;
ext4_ext_tree_init(handle, inode);
err = ext4_update_incompat_feature(handle, sb,
diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index da942bc..63c33e0 100644
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -,6 +,8 @@ retry:
goto out_stop;
}
} else {
+ /* clear the extent format for fast symlink */
+ EXT4_I(inode)->i_flags &= ~EXT4_EXTENTS_FL;
inode->i_op = &ext4_fast_symlink_inode_operations;
memcpy((char*)&EXT4_I(inode)->i_data,symname,l);
inode->i_size = l-1;
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in e2fsprogs.git (topics)
On Sun, Feb 24, 2008 at 09:20:50PM -0700, Andreas Dilger wrote: > On Feb 22, 2008 19:15 -0500, Theodore Ts'o wrote: > > So before the recent patch were we actually creating long symlinks in > > extents format? Or were we just setting the flag but still treating > > them as a block number? If it was the latter, I guess we can put in > > code into e2fsck to detect that case, and convert it back to a > > singleton block number. > > Eric informed me that the long symlinks were actually stored in extent > mapped blocks. That is not harmful, because it can only be a single > block and it will always fit into the inode. The other thing to note > is that extent mapping is REQUIRED for > 32-bit blocknumbers, so we > may as well fix e2fsprogs to allow these symlinks to be handled normally. Well, at least some kernel versions (as of sometime just before 2.6.25, iirc) were storing the long symlink as a single block in i_block[0], despite EXTENTS_FL being set. Valerie noticed this, and I confirmed it, as it caused the mainline e2fsck extents support to core dump. Basically, what this means is that e2fsprogs can't trust EXTENTS_FL for long symlinks. But you do raise a good point that we need to support using the extents format in order to support blocks > 2**32, so we can't just arbitrary convert all symlinks to the old-style direct block maps. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
