All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Theodore Tso <tytso@mit.edu>
Cc: Andreas Dilger <adilger@sun.com>,
	Eric Sandeen <sandeen@redhat.com>,
	linux-ext4@vger.kernel.org
Subject: Re: What's cooking in e2fsprogs.git (topics)
Date: Mon, 25 Feb 2008 21:31:36 +0530	[thread overview]
Message-ID: <20080225160136.GA5029@skywalker> (raw)
In-Reply-To: <20080225151339.GB8408@mit.edu>

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 <aneesh.kumar@linux.vnet.ibm.com>

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 <aneesh.kumar@linux.vnet.ibm.com>
---

 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
@@ -2222,6 +2222,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;

  reply	other threads:[~2008-02-25 16:01 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-04 22:42 What's cooking in e2fsprogs.git (topics) Theodore Ts'o, Theodore Ts'o
2007-11-05  2:15 ` Andreas Dilger
2007-11-05  4:32   ` Theodore Tso
2007-11-05 15:06     ` Andreas Dilger
2007-12-17 17:11 ` Theodore Tso
2007-12-17 22:34   ` Andreas Dilger
2007-12-17 22:59     ` Theodore Tso
2007-12-17 23:36       ` Andreas Dilger
2007-12-18  3:32         ` Theodore Tso
2007-12-18  8:13       ` Florian Weimer
2007-12-18 19:10   ` What's cooking in e2fsprogs.git (topics) - [RFC] FLEX_BG bmap and itable allocation patch Jose R. Santos
2008-02-11  4:51   ` What's cooking in e2fsprogs.git (topics) Theodore Tso
2008-02-11  5:08     ` Eric Sandeen
2008-02-11  7:24       ` Theodore Tso
2008-02-19  5:09     ` Theodore Tso
2008-02-20 18:46       ` Eric Sandeen
2008-02-21 14:05         ` Theodore Tso
2008-02-21 16:40           ` Eric Sandeen
2008-02-22 23:14             ` Andreas Dilger
2008-02-23  0:15               ` Theodore Tso
2008-02-25  4:20                 ` Andreas Dilger
2008-02-25 15:13                   ` Theodore Tso
2008-02-25 16:01                     ` Aneesh Kumar K.V [this message]
2008-02-25 17:32                     ` Eric Sandeen
2008-02-25 20:23                       ` Theodore Tso
2008-02-29 15:43       ` Theodore Tso
2008-02-29 19:59         ` Andreas Dilger
2008-02-29 22:49           ` Theodore Tso
2008-03-02  3:24         ` Jose R. Santos
2008-03-05 16:59         ` Jose R. Santos
2008-03-13 18:11         ` Theodore Tso
2008-03-20 20:32           ` Theodore Tso
2008-04-02  0:09         ` Theodore Tso
2008-04-07 17:12           ` Theodore Tso
2008-04-18 18:43             ` Theodore Tso
2008-04-21 16:41               ` Theodore Tso
2008-04-23  7:32                 ` Aneesh Kumar K.V
2008-04-23 11:55                   ` Theodore Tso
2008-04-23 18:58                 ` Aneesh Kumar K.V
2008-04-28 19:44                   ` The changes I made to the undo-mgr (Re: What's cooking in e2fsprogs.git (topics)) Theodore Tso
2008-05-24 23:54                 ` What's cooking in e2fsprogs.git (topics) Theodore Tso
2008-06-03  2:40                   ` Theodore Tso
2008-06-17 12:03                     ` Theodore Tso
2008-03-02 23:50       ` Christian Kujau
  -- strict thread matches above, loose matches on Subject: below --
2007-10-16  4:48 Theodore Ts'o
2007-10-16  5:36 ` Aneesh Kumar K.V
2007-10-16 16:41 ` Jose R. Santos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080225160136.GA5029@skywalker \
    --to=aneesh.kumar@linux.vnet.ibm.com \
    --cc=adilger@sun.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sandeen@redhat.com \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.