Patchwork [GIT,PULL] ext4 updates for 3.9

login
register
mail settings
Submitter Theodore Ts'o
Date Feb. 26, 2013, 8:39 p.m.
Message ID <nsxr4k2kdwv.fsf@closure.thunk.org>
Download mbox
Permalink /patch/223388/
State Rejected
Headers show

Pull-request

git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git tags/ext4_for_linus

Comments

Theodore Ts'o - Feb. 26, 2013, 8:39 p.m.
The following changes since commit 9931faca02c604c22335f5a935a501bb2ace6e20:

  Linux 3.8-rc3 (2013-01-09 18:59:55 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git tags/ext4_for_linus

for you to fetch changes up to 304e220f0879198b1f5309ad6f0be862b4009491:

  ext4: fix free clusters calculation in bigalloc filesystem (2013-02-22 15:27:52 -0500)

----------------------------------------------------------------
The one new feature added in this patch series is the ability to use
the "punch hole" functionality for inodes that are not using extent
maps.

In the bug fix category, we fixed some races in the AIO and fstrim
code, and some potential NULL pointer dereferences and memory leaks in
error handling code paths.

In the optimization category, we fixed a performance regression in the
jbd2 layer introduced by commit d9b0193 (introduced in v3.0) which
shows up in the AIM7 benchmark.  We also further optimized jbd2 by
minimize the amount of time that transaction handles are held active.

This patch series also features some additional enhancement of the
extent status tree, which is now used to cache extent information in a
more efficient/compact form than what we use on-disk.

----------------------------------------------------------------
Akria Fujita (1):
      ext4: fix smatch warning in move_extent.c's mext_replace_branches()

Chen Gang (1):
      ext4: fix memory leak when quota options are specified multiple times

Cong Ding (1):
      ext4: reduce one "if" comparison in ext4_dirhash()

Eric Sandeen (1):
      jbd2: don't wake kjournald unnecessarily

Eryu Guan (2):
      ext4: check bh in ext4_read_block_bitmap()
      ext4: no need to remove extent if len is 0 in ext4_es_remove_extent()

Guo Chao (4):
      ext4: release buffer when checksum failed
      ext4: remove unused variable in add_dirent_to_buf()
      ext4: remove useless assignment in dx_probe()
      ext4: remove unnecessary NULL pointer check

Jan Kara (13):
      ext4: Always use ext4_bio_write_page() for writeout
      ext4: use redirty_page_for_writepage() in ext4_bio_write_page()
      ext4: remove __ext4_journalled_writepage() from mpage_da_submit_io()
      ext4: move work from io_end to inode
      ext4: simplify list handling in ext4_do_flush_completed_IO()
      ext4: dirty page has always buffers attached
      ext4: simplify mpage_add_bh_to_extent()
      ext4: Make ext4_bio_writepage() handle unprepared buffers
      ext4: fix ext4_writepage() to achieve data=ordered guarantees
      ext4: fix possible use-after-free with AIO
      ext4: move several mount options to standard handling loop
      ext4: make mount option parsing loop more logical
      ext4: print error when argument of inode_readahead_blk is invalid

Julia Lawall (1):
      ext4: use WARN in ext4_alloc_blocks

Lukas Czerner (4):
      ext4: remove unused variable flags
      ext4: remove explicit WARN_ON when ext4_map_blocks() fails
      ext4: fix xattr block allocation/release with bigalloc
      ext4: fix free clusters calculation in bigalloc filesystem

Niu Yawei (1):
      ext4: fix race in ext4_mb_add_n_trim()

Theodore Ts'o (24):
      ext4: return ENOMEM if sb_getblk() fails
      ext4: trigger the lazy inode table initialization after resize
      ext4: release sysfs kobject when failing to enable quotas on mount
      quota: autoload the quota_v2 module for QFMT_VFS_V1 quota format
      ext4: check incompatible mount options while mounting ext2/3
      ext4: optimize mballoc for large allocations
      jbd2: track request delay statistics
      jbd2: revert "jbd2: add COW fields to struct jbd2_journal_handle"
      jbd2: add tracepoints which provide per-handle statistics
      ext4: move the jbd2 wrapper functions out of super.c
      ext4: pass context information to jbd2__journal_start()
      ext4: grab page before starting transaction handle in write_begin()
      ext4: start handle at the last possible moment in ext4_unlink()
      ext4: start handle at the last possible moment in ext4_rmdir()
      ext4: fix the number of credits needed for ext4_ext_migrate()
      ext4: fix the number of credits needed for ext4_unlink() and ext4_rmdir()
      ext4: fix the number of credits needed for acl ops with inline data
      ext4: start handle at the last possible moment when creating inodes
      ext4: use module parameters instead of debugfs for mballoc_debug
      jbd2: use module parameters instead of debugfs for jbd_debug
      ext4: use KERN_WARNING for warning messages
      ext4: add debugging context for warning in ext4_da_update_reserve_space()
      ext4: refactor code to read directory blocks into ext4_read_dirblock()
      ext4: use ERR_PTR() abstraction for ext4_append()

Wang Shilong (1):
      ext4: use unlikely to improve the efficiency of the kernel

Zheng Liu (11):
      ext4: add tracepoint in punching hole
      ext4: add punching hole support for non-extent-mapped files
      ext4: refine extent status tree
      ext4: add physical block and status member into extent status tree
      ext4: rename and improbe ext4_es_find_extent()
      ext4: let ext4_ext_map_blocks return EXT4_MAP_UNWRITTEN flag
      ext4: track all extent status in extent status tree
      ext4: lookup block mapping in extent status tree
      ext4: remove single extent cache
      ext4: adjust some functions for reclaiming extents from extent status tree
      ext4: reclaim extents from extent status tree

 fs/ext4/acl.c               |   7 +-
 fs/ext4/balloc.c            |  13 +-
 fs/ext4/dir.c               |   1 +
 fs/ext4/ext4.h              | 123 ++++++--
 fs/ext4/ext4_extents.h      |   6 -
 fs/ext4/ext4_jbd2.c         | 102 +++++++
 fs/ext4/ext4_jbd2.h         |  51 +++-
 fs/ext4/extents.c           | 312 ++++++++-------------
 fs/ext4/extents_status.c    | 631 ++++++++++++++++++++++++++++++-----------
 fs/ext4/extents_status.h    |  83 +++++-
 fs/ext4/file.c              |  16 +-
 fs/ext4/hash.c              |   6 +-
 fs/ext4/ialloc.c            |  29 +-
 fs/ext4/indirect.c          | 259 ++++++++++++++++-
 fs/ext4/inline.c            |  12 +-
 fs/ext4/inode.c             | 664 ++++++++++++++++++++------------------------
 fs/ext4/ioctl.c             |  13 +-
 fs/ext4/mballoc.c           |  69 ++---
 fs/ext4/mballoc.h           |   4 +-
 fs/ext4/migrate.c           |  15 +-
 fs/ext4/mmp.c               |   4 +-
 fs/ext4/move_extent.c       |  10 +-
 fs/ext4/namei.c             | 497 +++++++++++++++------------------
 fs/ext4/page-io.c           |  85 ++----
 fs/ext4/resize.c            |  36 +--
 fs/ext4/super.c             | 485 ++++++++++++++------------------
 fs/ext4/xattr.c             |  23 +-
 fs/ext4/xattr.h             |  68 -----
 fs/jbd2/commit.c            |   8 +
 fs/jbd2/journal.c           |  66 ++---
 fs/jbd2/transaction.c       |  29 +-
 include/linux/jbd2.h        |  44 ++-
 include/linux/quota.h       |   1 +
 include/trace/events/ext4.h | 214 +++++++++++---
 include/trace/events/jbd2.h | 106 ++++++-
 35 files changed, 2408 insertions(+), 1684 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Markus Trippelsdorf - Feb. 27, 2013, 12:47 p.m.
On 2013.02.26 at 15:39 -0500, Theodore Ts'o wrote:
> 
> The following changes since commit 9931faca02c604c22335f5a935a501bb2ace6e20:
> 
>   Linux 3.8-rc3 (2013-01-09 18:59:55 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git tags/ext4_for_linus

Just booted todays Linux tree and got the following errors:

...
Feb 27 13:33:31 x4 kernel: EXT4-fs (sda): mounted filesystem with ordered data mode. Opts: (null)
...
Feb 27 13:33:32 x4 kernel: EXT4-fs error (device sda): ext4_find_dest_de:1657: inode #70647809: block 14164000: comm cupsd: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=2569822761, rec_len=3837, name_len=1
Feb 27 13:33:32 x4 kernel: EXT4-fs error (device sda): ext4_find_dest_de:1657: inode #70911401: block 15213579: comm pdnsd: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=2000846358, rec_len=36782, name_len=120

/dev/sda       ext4      1.4T  655G  651G  51% /var
/dev/sda on /var type ext4 (rw,noatime,data=ordered)

Running "fsck.ext4 -f /dev/sda" shows no problems.
Theodore Ts'o - Feb. 27, 2013, 3:34 p.m.
On Wed, Feb 27, 2013 at 01:47:27PM +0100, Markus Trippelsdorf wrote:
> Just booted todays Linux tree and got the following errors:
> 
> ...
> Feb 27 13:33:31 x4 kernel: EXT4-fs (sda): mounted filesystem with ordered data mode. Opts: (null)
> ...
> Feb 27 13:33:32 x4 kernel: EXT4-fs error (device sda): ext4_find_dest_de:1657: inode #70647809: block 14164000: comm cupsd: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=2569822761, rec_len=3837, name_len=1
> Feb 27 13:33:32 x4 kernel: EXT4-fs error (device sda): ext4_find_dest_de:1657: inode #70911401: block 15213579: comm pdnsd: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=2000846358, rec_len=36782, name_len=120

Is this reproducible?  This looks like the in-memory copy of the
directory got corrupted.  This could be caused by a hardware error, or
a wild pointer, or a bug in the buffer cache code, etc.  Since there
are so many different possible causes of this kind of complaint, we
really need some kind of reproducible test case to do anything with this.

I did do a test compile of the ext4 tree with the latest linus.git
tree merged in, and ran a full set of repgression tests before I sent
my pull request.  Now, the regression tests take over 14 hours to run,
and there is a delay between when a maintainer sends the pull request
to when Linus acts on it --- so Linus almost certainly pulled in some
other trees betewen when I did my final regression testing and when I
sent the pull request and he pulled it into my tree.

I'll see if I can reproduce this on my end, on Linus's tree after the
ext4 tree was merged in, but at least in the past, this is the sort of
thing that is almost certainly caused by a hardware failure or bug
somewhere in the device driver, mm, or buffer cache, given that the
directory looks completely insane and a subsequent e2fsck -f didn't
discover any problem.

Is there anything special about your system?  How much memory do you
have?  What kind of device is /dev/sda?  What sort of workload did you
have running on your system before the failure?

Also, can you send us the output of "debugfs -R "stat <70647809>"
/dev/sda" so I can confirm that block 14164000 really is assigned to
inode 70647809?  The one potential cause of this error I can think of
that might be related to recent changes in ext4 is if the extent
status tree had the wrong logical-to-physical mapping cached for the
directory inode.

Regards,

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Markus Trippelsdorf - Feb. 27, 2013, 3:44 p.m.
On 2013.02.27 at 10:34 -0500, Theodore Ts'o wrote:
> On Wed, Feb 27, 2013 at 01:47:27PM +0100, Markus Trippelsdorf wrote:
> > Just booted todays Linux tree and got the following errors:
> > 
> > ...
> > Feb 27 13:33:31 x4 kernel: EXT4-fs (sda): mounted filesystem with ordered data mode. Opts: (null)
> > ...
> > Feb 27 13:33:32 x4 kernel: EXT4-fs error (device sda): ext4_find_dest_de:1657: inode #70647809: block 14164000: comm cupsd: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=2569822761, rec_len=3837, name_len=1
> > Feb 27 13:33:32 x4 kernel: EXT4-fs error (device sda): ext4_find_dest_de:1657: inode #70911401: block 15213579: comm pdnsd: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=2000846358, rec_len=36782, name_len=120
> 
> Is this reproducible? 

Haven't checked yet, because I got scared.

> Is there anything special about your system?  How much memory do you
> have?  What kind of device is /dev/sda?  What sort of workload did you
> have running on your system before the failure?

There is nothing special about my system. /dev/sda is a standard SATA
drive: 
 Model Family:     Seagate Barracuda Green (AF)
 Device Model:     ST1500DL003-9VT16L
The error happens during boot.
I use ECC memory.

> Also, can you send us the output of "debugfs -R "stat <70647809>"
> /dev/sda" so I can confirm that block 14164000 really is assigned to
> inode 70647809?  The one potential cause of this error I can think of
> that might be related to recent changes in ext4 is if the extent
> status tree had the wrong logical-to-physical mapping cached for the
> directory inode.

Inode: 70647809   Type: directory    Mode:  0755   Flags: 0x80000
Generation: 4138624941    Version: 0x00000000:0000000d
User:     0   Group:     0   Size: 4096
File ACL: 0    Directory ACL: 0
Links: 13   Blockcount: 8
Fragment:  Address: 0    Number: 0    Size: 0
 ctime: 0x50ab80de:2c77d5bc -- Tue Nov 20 14:08:46 2012
 atime: 0x50aa5519:c556886c -- Mon Nov 19 16:49:45 2012
 mtime: 0x50ab80de:2c77d5bc -- Tue Nov 20 14:08:46 2012
crtime: 0x50aa4a81:06bc6fd0 -- Mon Nov 19 16:04:33 2012
Size of extra inode fields: 28
EXTENTS:
(0):282599456
Markus Trippelsdorf - Feb. 27, 2013, 5:01 p.m.
On 2013.02.27 at 16:44 +0100, Markus Trippelsdorf wrote:
> On 2013.02.27 at 10:34 -0500, Theodore Ts'o wrote:
> > On Wed, Feb 27, 2013 at 01:47:27PM +0100, Markus Trippelsdorf wrote:
> > > Just booted todays Linux tree and got the following errors:
> > > 
> > > ...
> > > Feb 27 13:33:31 x4 kernel: EXT4-fs (sda): mounted filesystem with ordered data mode. Opts: (null)
> > > ...
> > > Feb 27 13:33:32 x4 kernel: EXT4-fs error (device sda): ext4_find_dest_de:1657: inode #70647809: block 14164000: comm cupsd: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=2569822761, rec_len=3837, name_len=1
> > > Feb 27 13:33:32 x4 kernel: EXT4-fs error (device sda): ext4_find_dest_de:1657: inode #70911401: block 15213579: comm pdnsd: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=2000846358, rec_len=36782, name_len=120
> > 
> > Is this reproducible? 

The issue is caused by:

commit d100eef2440fea13e4f09e88b1c8bcbca64beb9f
Author: Zheng Liu <wenqing.lz@taobao.com>
Date:   Mon Feb 18 00:29:59 2013 -0500

    ext4: lookup block mapping in extent status tree
Zheng Liu - Feb. 27, 2013, 5:10 p.m.
在 2013-2-28,上午1:01,Markus Trippelsdorf <markus@trippelsdorf.de> 写道:

> On 2013.02.27 at 16:44 +0100, Markus Trippelsdorf wrote:
>> On 2013.02.27 at 10:34 -0500, Theodore Ts'o wrote:
>>> On Wed, Feb 27, 2013 at 01:47:27PM +0100, Markus Trippelsdorf wrote:
>>>> Just booted todays Linux tree and got the following errors:
>>>> 
>>>> ...
>>>> Feb 27 13:33:31 x4 kernel: EXT4-fs (sda): mounted filesystem with ordered data mode. Opts: (null)
>>>> ...
>>>> Feb 27 13:33:32 x4 kernel: EXT4-fs error (device sda): ext4_find_dest_de:1657: inode #70647809: block 14164000: comm cupsd: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=2569822761, rec_len=3837, name_len=1
>>>> Feb 27 13:33:32 x4 kernel: EXT4-fs error (device sda): ext4_find_dest_de:1657: ignore#70911401: block 15213579: comm pdnsd: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=2000846358, rec_len=36782, name_len=120
>>> 
>>> Is this reproducible? 
> 
> The issue is caused by:
> 
> commit d100eef2440fea13e4f09e88b1c8bcbca64beb9f
> Author: Zheng Liu <wenqing.lz@taobao.com>
> Date:   Mon Feb 18 00:29:59 2013 -0500
> 
>    ext4: lookup block mapping in extent status tree

Hi Markus,

Thanks for the report.  I am very sorry about that.  Now I am trying to fix it.

Thanks,
                                                - Zheng--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Markus Trippelsdorf - Feb. 27, 2013, 5:22 p.m.
On 2013.02.28 at 01:10 +0800, gnehzuil.liu wrote:
> 在 2013-2-28,上午1:01,Markus Trippelsdorf <markus@trippelsdorf.de> 写道:
> 
> > On 2013.02.27 at 16:44 +0100, Markus Trippelsdorf wrote:
> >> On 2013.02.27 at 10:34 -0500, Theodore Ts'o wrote:
> >>> On Wed, Feb 27, 2013 at 01:47:27PM +0100, Markus Trippelsdorf wrote:
> >>>> Just booted todays Linux tree and got the following errors:
> >>>> 
> >>>> ...
> >>>> Feb 27 13:33:31 x4 kernel: EXT4-fs (sda): mounted filesystem with ordered data mode. Opts: (null)
> >>>> ...
> >>>> Feb 27 13:33:32 x4 kernel: EXT4-fs error (device sda): ext4_find_dest_de:1657: inode #70647809: block 14164000: comm cupsd: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=2569822761, rec_len=3837, name_len=1
> >>>> Feb 27 13:33:32 x4 kernel: EXT4-fs error (device sda): ext4_find_dest_de:1657: ignore#70911401: block 15213579: comm pdnsd: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=2000846358, rec_len=36782, name_len=120
> >>> 
> >>> Is this reproducible? 
> > 
> > The issue is caused by:
> > 
> > commit d100eef2440fea13e4f09e88b1c8bcbca64beb9f
> > Author: Zheng Liu <wenqing.lz@taobao.com>
> > Date:   Mon Feb 18 00:29:59 2013 -0500
> > 
> >    ext4: lookup block mapping in extent status tree
> 
> Thanks for the report.  I am very sorry about that.  Now I am trying to fix it.
> 
Thank you.

Please note that if I run a kernel build with: 
"git reset --hard f7fec032aa782d3fd7e51fbdf08aa3a296c01500" 
(the commit before d100eef24) I get a different but similar error:

  EXT4-fs (sda): error count: 4
  EXT4-fs (sda): initial error at 1361983458: ext4_find_dest_de:1657: inode 70911401: block 15213579 
  EXT4-fs (sda): last error at 1361983663: ext4_find_dest_de:1658: inode 70647809: block 14164000
Zheng Liu - Feb. 27, 2013, 5:38 p.m.
在 2013-2-28,上午1:22,Markus Trippelsdorf <markus@trippelsdorf.de> 写道:

> On 2013.02.28 at 01:10 +0800, gnehzuil.liu wrote:
>> 在 2013-2-28,上午1:01,Markus Trippelsdorf <markus@trippelsdorf.de> 写道:
>> 
>>> On 2013.02.27 at 16:44 +0100, Markus Trippelsdorf wrote:
>>>> On 2013.02.27 at 10:34 -0500, Theodore Ts'o wrote:
>>>>> On Wed, Feb 27, 2013 at 01:47:27PM +0100, Markus Trippelsdorf wrote:
>>>>>> Just booted todays Linux tree and got the following errors:
>>>>>> 
>>>>>> ...
>>>>>> Feb 27 13:33:31 x4 kernel: EXT4-fs (sda): mounted filesystem with ordered data mode. Opts: (null)
>>>>>> ...
>>>>>> Feb 27 13:33:32 x4 kernel: EXT4-fs error (device sda): ext4_find_dest_de:1657: inode #70647809: block 14164000: comm cupsd: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=2569822761, rec_len=3837, name_len=1
>>>>>> Feb 27 13:33:32 x4 kernel: EXT4-fs error (device sda): ext4_find_dest_de:1657: ignore#70911401: block 15213579: comm pdnsd: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=2000846358, rec_len=36782, name_len=120
>>>>> 
>>>>> Is this reproducible? 
>>> 
>>> The issue is caused by:
>>> 
>>> commit d100eef2440fea13e4f09e88b1c8bcbca64beb9f
>>> Author: Zheng Liu <wenqing.lz@taobao.com>
>>> Date:   Mon Feb 18 00:29:59 2013 -0500
>>> 
>>>   ext4: lookup block mapping in extent status tree
>> 
>> Thanks for the report.  I am very sorry about that.  Now I am trying to fix it.
>> 
> Thank you.
> 
> Please note that if I run a kernel build with: 
> "git reset --hard f7fec032aa782d3fd7e51fbdf08aa3a296c01500" 
> (the commit before d100eef24) I get a different but similar error:
> 
>  EXT4-fs (sda): error count: 4
>  EXT4-fs (sda): initial error at 1361983458: ext4_find_dest_de:1657: inode 70911401: block 15213579 
>  EXT4-fs (sda): last error at 1361983663: ext4_find_dest_de:1658: inode 70647809: block 14164000

Yup, thanks for the note.  Could you please revert to this commit a25a4e1a5d5dc0f97dddbca44e695c532d8228c1 (the commit before f7fec032)?  I suspect that commit f7fec032 is the root cause.  Thanks for your help.

Regards,
                                                - Zheng--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Markus Trippelsdorf - Feb. 27, 2013, 5:45 p.m.
On 2013.02.28 at 01:38 +0800, gnehzuil.liu wrote:
> 在 2013-2-28,上午1:22,Markus Trippelsdorf <markus@trippelsdorf.de> 写道:
> 
> > On 2013.02.28 at 01:10 +0800, gnehzuil.liu wrote:
> >> 在 2013-2-28,上午1:01,Markus Trippelsdorf <markus@trippelsdorf.de> 写道:
> >> 
> >>> On 2013.02.27 at 16:44 +0100, Markus Trippelsdorf wrote:
> >>>> On 2013.02.27 at 10:34 -0500, Theodore Ts'o wrote:
> >>>>> On Wed, Feb 27, 2013 at 01:47:27PM +0100, Markus Trippelsdorf wrote:
> >>>>>> Just booted todays Linux tree and got the following errors:
> >>>>>> 
> >>>>>> ...
> >>>>>> Feb 27 13:33:31 x4 kernel: EXT4-fs (sda): mounted filesystem with ordered data mode. Opts: (null)
> >>>>>> ...
> >>>>>> Feb 27 13:33:32 x4 kernel: EXT4-fs error (device sda): ext4_find_dest_de:1657: inode #70647809: block 14164000: comm cupsd: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=2569822761, rec_len=3837, name_len=1
> >>>>>> Feb 27 13:33:32 x4 kernel: EXT4-fs error (device sda): ext4_find_dest_de:1657: ignore#70911401: block 15213579: comm pdnsd: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=2000846358, rec_len=36782, name_len=120
> >>>>> 
> >>>>> Is this reproducible? 
> >>> 
> >>> The issue is caused by:
> >>> 
> >>> commit d100eef2440fea13e4f09e88b1c8bcbca64beb9f
> >>> Author: Zheng Liu <wenqing.lz@taobao.com>
> >>> Date:   Mon Feb 18 00:29:59 2013 -0500
> >>> 
> >>>   ext4: lookup block mapping in extent status tree
> >> 
> >> Thanks for the report.  I am very sorry about that.  Now I am trying to fix it.
> >> 
> > Thank you.
> > 
> > Please note that if I run a kernel build with: 
> > "git reset --hard f7fec032aa782d3fd7e51fbdf08aa3a296c01500" 
> > (the commit before d100eef24) I get a different but similar error:
> > 
> >  EXT4-fs (sda): error count: 4
> >  EXT4-fs (sda): initial error at 1361983458: ext4_find_dest_de:1657: inode 70911401: block 15213579 
> >  EXT4-fs (sda): last error at 1361983663: ext4_find_dest_de:1658: inode 70647809: block 14164000
> 
> Yup, thanks for the note.  Could you please revert to this commit
> a25a4e1a5d5dc0f97dddbca44e695c532d8228c1 (the commit before f7fec032)?
> I suspect that commit f7fec032 is the root cause.  Thanks for your
> help. 

git revert 06b0c886214a223dde7b21cbfc3008fd20a8ce16..74cd15cd02708c7188581f279f33a98b2ae8d322
fixes all issues...
Linus Torvalds - Feb. 27, 2013, 5:52 p.m.
On Wed, Feb 27, 2013 at 9:45 AM, Markus Trippelsdorf
<markus@trippelsdorf.de> wrote:
>
> git revert 06b0c886214a223dde7b21cbfc3008fd20a8ce16..74cd15cd02708c7188581f279f33a98b2ae8d322
> fixes all issues...

Hmm. I'm hoping this will have a quick resolution that doesn't mean
having to revert all that. But it's good to have the option.

Zheng, Ted, I'm holding up further merging (ugh, second time this
merge window) in the hope that we can get this sorted out quickly. I
hate continuing to merge stuff when there are known nasty issues
pending in my tree.

I can't hold for all that long, but it would be really nice if this
got sorted out quickly.

                   Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html