headers
Yongqiang Yang | 1 Jun 2011 03:58
Picon

Re: xfsprogs: Fix for xfstest 252 hang on ext4

On Tue, May 31, 2011 at 11:25 PM, Allison Henderson
<achender <at> linux.vnet.ibm.com> wrote:
> On 5/23/2011 7:38 PM, Allison Henderson wrote:
>>
>> On 5/23/2011 6:16 PM, Yongqiang Yang wrote:
>>>
>>> On Tue, May 24, 2011 at 4:34 AM, Allison Henderson
>>> <achender <at> linux.vnet.ibm.com> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> While trying to add more punch hole tests to xfstest, I found that
>>>> test 252 hangs on ext4 due to a loop in xfsprogs that does not exit.
>>>> XFS gets out of this loop because there is logic in the loop that
>>>> looks for the last extent flag and breaks out. But it looks like ext4
>>>> does not return a last extent when the file has a hole at the end. I
>>>> am not sure if this is the correct behavior or not, so I will copy
>>>> the ext4 folks on this too. Below is a copy of the fix for xfsprogs:
>>>
>>> Hi there,
>>>
>>> What's blocksize of the tested ext4? For now, ext4 returns
>>> LAST_EXTENT if the logical offset covered by the extent is greater
>>> than file size, so if there is a hole at the end, no last extent is
>>> returned. Thx!
>>>
>>> Yongqiang.
>>
>> Hi there,
>>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ted Ts'o | 1 Jun 2011 02:00
Picon
Picon
Favicon
Gravatar

Re: [PATCH] e2fsck: don't check/clone duplicate xattr blocks in fs without xattr feature

On Wed, Feb 09, 2011 at 12:41:43PM -0600, Eric Sandeen wrote:
> I had an extremely corrupted customer filesystem which, after thousands
> of lines of e2fsck output, found one more problem on an immediately
> subsequent e2fsck.  In short, a file had had its i_file_acl block
> cloned due to being a duplicate.  That ultimately got cleared
> because the fs did not have the xattr feature, and the inode
> was subsequently removed due to invalid mode.
> 
> The 2nd e2fsck pass found the cloned xattr block as in use, but
> not owned by any file, and had to fix up the block bitmaps.
> 
> Simply skipping the processing of duplicate xattr blocks on a
> non-xattr filesystem seems reasonable, since they will be cleared
> later in any case.
> 
> (also fix existing brace misalignment)
> 
> Signed-off-by: Eric Sandeen <sandeen <at> redhat.com>

Applied, sorry for the delay.

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Ted Ts'o | 1 Jun 2011 01:45
Picon
Picon
Favicon
Gravatar

Re: [PATCH 1/2 v3] e2fsprogs: Fix how we treat user-spcified filesystem size

On Fri, May 20, 2011 at 05:36:47PM +0200, Lukas Czerner wrote:
> mke2fs and resize2fs allows specifying filesystem size as a parameter,
> former called as blocks-count. However it has been a little bit messy so
> this commit fixes it mainly by updating man pages.
> 
> We can not specify filesystem size in blocks count without specifying
> blocksize as well. It is because we need blocks count to determine
> filesystem type, and we need filesystem type to determine blocksize. So
> it should not be allowed, however due to compatibility reason it should
> be still possible, so at least print warning message for now, so we can
> easily restrict that later.
> 
> Filesystem size can be specified using units as suffixes. This was not
> documented for mke2fs, so this commits adds proper documentation into
> mke2fs man page.
> 
> For the sake of completeness add 'b' (filesystem blocks) unit.

I'd much rather fix this by documenting that without a suffix, it will
be interpreted as the number of blocks if -b is specified, and that if
-b is not specified, it will be interpreted as kilobytes (but that
this usage is deprecated).

>  <at>  <at>  -37,6 +38,14  <at>  <at>  unsigned long long parse_num_blocks2(const char *arg, int log_block_size)
>  		num >>= (1+log_block_size);
>  		break;
>  	case '\0':
> +	case 'b':
> +		if (!log_block_size) {
> +			fprintf(stderr,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ted Ts'o | 1 Jun 2011 02:11
Picon
Picon
Favicon
Gravatar

Re: [PATCH] tune2fs: Fix overflow of interval check

On Tue, Apr 19, 2011 at 03:11:39PM +0900, Kazuya Mio wrote:
> Add the check of maximum check interval.
> s_checkinterval is 32bit variable, so it cannot be set more than 2^32.
> 
> Signed-off-by: Kazuya Mio <k-mio <at> sx.jp.nec.com>

Applied, thanks.

					- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Ted Ts'o | 1 Jun 2011 02:11
Picon
Picon
Favicon
Gravatar

Re: [PATCH] e2fsprogs: Unify the upper limit of reserved blocks count

On Tue, Apr 19, 2011 at 03:11:34PM +0900, Kazuya Mio wrote:
> In e2fsprogs, the upper limit of reserved blocks count is a half of
> filesystem's blocks count. This patch fixes the incorrect checks of
> reserved blocks count.
> 
> Signed-off-by: Kazuya Mio <k-mio <at> sx.jp.nec.com>

Applied, thanks.

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Ted Ts'o | 1 Jun 2011 01:56
Picon
Picon
Favicon
Gravatar

Re: [3/3] libext2fs: pick out UNINIT-EXTENT block

On Sat, Jan 29, 2011 at 08:28:34PM -0000, Robin Dong wrote:
> From: Robin Dong <sanbai <at> taobao.com>
> 
> for display UNINIT-EXTENT block usage in dumpe2fs, modify 
> ext2fs_block_iterate3 to distinguish between uninitial extent
> block and normal extent block
> 
> Signed-off-by: Robing Dong <sanbai <at> taobao.com>
> 
> ---
> lib/ext2fs/block.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/lib/ext2fs/block.c b/lib/ext2fs/block.c
> index 0e4ec77..c7a60da 100644
> --- a/lib/ext2fs/block.c
> +++ b/lib/ext2fs/block.c
>  <at>  <at>  -458,7 +458,7  <at>  <at>  errcode_t ext2fs_block_iterate3(ext2_filsys fs,
>  			     blk++, blockcnt++, j++) {
>  				new_blk = blk;
>  				r = (*ctx.func)(fs, &new_blk, blockcnt,
> -						0, 0, priv_data);
> +						extent.e_flags, 0, priv_data);

Apologies for not getting back to this earlier, but I don't want to
overload the ref_blk field, since it will have a very different
meaning for extent-mapped and files mapped using the traditional
indirect block scheme.  This could potentially confuse callers who
don't know about extents.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Amir Goldstein | 1 Jun 2011 05:13
Picon
Gravatar

[PATCH] xfstests: add support for ext4dev FSTYP

From: Amir Goldstein <amir73il <at> users.sf.net>

blkid knows to identify the ext4dev FSTYP of a partition that was
formatted with mkfs.ext4dev.
quota tools and various util-linux utils are also aware of ext4dev,
so ext4dev shares the same capabilities as ext4.

While testing on Fedora 15, we encoutered a buggy fsck utility, which
invokes fsck.ext4, even though it was called with -t ext4dev argument.
In our setup fsck.ext4dev knows about new fs features that fsck.ext4
doesn't know, so the generic_fs_check fails.
Since we have no real use of the extra capabilities provided by fsck util,
we decided to invoke fsck.$FSTYP directly to avoid this issue.

Signed-off-by: Amir Goldstein <amir73il <at> users.sf.net>
Tested-by: Sergey Ivanov <sergey57 <at> gmail.com>
---
ext4dev is used to test experimental ext4 code in mutual existance
with production ext4 code on the same system.

Specifically, ext4 snapshots code is available for testing as a
stand-alone ext4dev module for Fedora 15 and Ubuntu 11.4
(see http://next3.sf.net).

 common.defrag |    2 +-
 common.quota  |    4 ++--
 common.rc     |   12 ++++++------
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/common.defrag b/common.defrag
(Continue reading)

Permalink | Reply | 17 comments |
headers
Ted Ts'o | 1 Jun 2011 06:15
Picon
Picon
Favicon
Gravatar

Re: errors in ext4_mb_generate_buddy and ext4_remount

On Wed, Jun 01, 2011 at 12:38:13AM +0200, Christoph Anton Mitterer wrote:
> Hi Ted.
> 
> On Sun, 2011-05-08 at 21:01 -0400, Ted Ts'o wrote:
> > The debian packages of e2fsprogs version 1.41.14-1 in experimental, or
> > 1.41.12-4 in unstable, has the necessary new code in e2fsck.  I'm
> > working on getting the patch pushed to Debian obsolete^H^H^H^H^H^H^H
> > stable; hopefully that will happen in the next week or two.
> The problem at least persists in the 1.41.12-4 version.

Um, are you sure?  Try forcing an fsck run on the file systems in question.

    	    	       	       	       - Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Amir Goldstein | 1 Jun 2011 06:56
Picon
Gravatar

Re: [PATCH] xfstests: add support for ext4dev FSTYP

On Wed, Jun 1, 2011 at 7:37 AM, Eric Sandeen <sandeen <at> redhat.com> wrote:
> On 5/31/11 10:13 PM, Amir Goldstein wrote:
>> From: Amir Goldstein <amir73il <at> users.sf.net>
>>
>> blkid knows to identify the ext4dev FSTYP of a partition that was
>> formatted with mkfs.ext4dev.
>> quota tools and various util-linux utils are also aware of ext4dev,
>> so ext4dev shares the same capabilities as ext4.
>>
>> While testing on Fedora 15, we encoutered a buggy fsck utility, which
>> invokes fsck.ext4, even though it was called with -t ext4dev argument.
>> In our setup fsck.ext4dev knows about new fs features that fsck.ext4
>> doesn't know, so the generic_fs_check fails.
>> Since we have no real use of the extra capabilities provided by fsck util,
>> we decided to invoke fsck.$FSTYP directly to avoid this issue.
>
> Adding ext4dev to every case seems harmless enough.  TBH I thought I had
> it there already but I guess not.
>
> I'm less certain of the change from fsck -t $FSTYP to fsck.$FSTYP
>
> What issue are you avoiding?  wouldn't fsck -t ext4dev invoke fsck.ext4dev anyway?
>
> It seems like it should be harmless, but I don't understand how it helps you.
>

As I wrote in the patch description, the fsck utility in Fedora 15 invokes
fsck.ext4 for some reason when calling fsck -t ext4dev.
this fails because fsck.ext4 doesn't know the snapshot feature.
I didn't debug fsck utility for that. it seemed pointless.
(Continue reading)

Permalink | Reply | 11 comments |
headers
Eric Sandeen | 1 Jun 2011 07:22
Picon
Favicon
Gravatar

Re: [PATCH] xfstests: add support for ext4dev FSTYP

On 5/31/11 11:56 PM, Amir Goldstein wrote:
> On Wed, Jun 1, 2011 at 7:37 AM, Eric Sandeen <sandeen <at> redhat.com> wrote:
>> On 5/31/11 10:13 PM, Amir Goldstein wrote:
>>> From: Amir Goldstein <amir73il <at> users.sf.net>
>>>
>>> blkid knows to identify the ext4dev FSTYP of a partition that was
>>> formatted with mkfs.ext4dev.
>>> quota tools and various util-linux utils are also aware of ext4dev,
>>> so ext4dev shares the same capabilities as ext4.
>>>
>>> While testing on Fedora 15, we encoutered a buggy fsck utility, which
>>> invokes fsck.ext4, even though it was called with -t ext4dev argument.
>>> In our setup fsck.ext4dev knows about new fs features that fsck.ext4
>>> doesn't know, so the generic_fs_check fails.
>>> Since we have no real use of the extra capabilities provided by fsck util,
>>> we decided to invoke fsck.$FSTYP directly to avoid this issue.
>>
>> Adding ext4dev to every case seems harmless enough.  TBH I thought I had
>> it there already but I guess not.
>>
>> I'm less certain of the change from fsck -t $FSTYP to fsck.$FSTYP
>>
>> What issue are you avoiding?  wouldn't fsck -t ext4dev invoke fsck.ext4dev anyway?
>>
>> It seems like it should be harmless, but I don't understand how it helps you.
>>
> 
> As I wrote in the patch description, the fsck utility in Fedora 15 invokes
> fsck.ext4 for some reason when calling fsck -t ext4dev.
(Continue reading)

Permalink | Reply | 9 comments |

Gmane