| 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_linusComments
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.
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
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
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
在 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
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
在 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
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...
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
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