All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH 2/5] ext4: Move orphan inode handling into a separate file
@ 2021-07-13  4:49 kernel test robot
  0 siblings, 0 replies; 8+ messages in thread
From: kernel test robot @ 2021-07-13  4:49 UTC (permalink / raw)
  To: kbuild

[-- Attachment #1: Type: text/plain, Size: 5043 bytes --]

CC: kbuild-all(a)lists.01.org
In-Reply-To: <20210712154009.9290-3-jack@suse.cz>
References: <20210712154009.9290-3-jack@suse.cz>
TO: Jan Kara <jack@suse.cz>
TO: Ted Tso <tytso@mit.edu>
CC: linux-ext4(a)vger.kernel.org
CC: Jan Kara <jack@suse.cz>
CC: Andreas Dilger <adilger@dilger.ca>

Hi Jan,

I love your patch! Perhaps something to improve:

[auto build test WARNING on ext3/for_next]
[cannot apply to ext4/dev linus/master tytso-fscrypt/master v5.14-rc1 next-20210712]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Jan-Kara/ext4-Speedup-orphan-file-handling/20210712-234039
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git for_next
:::::: branch date: 13 hours ago
:::::: commit date: 13 hours ago
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>


cppcheck possible warnings: (new ones prefixed by >>, may not real problems)

   In file included from fs/ext4/orphan.c:
>> fs/ext4/orphan.c:323:5: warning: Identical inner 'if' condition is always true. [identicalInnerCondition]
       ext4_std_error(inode->i_sb, ret);
       ^
   fs/ext4/orphan.c:322:8: note: outer condition: ret
      if (ret)
          ^
   fs/ext4/orphan.c:323:5: note: identical inner condition: ret
       ext4_std_error(inode->i_sb, ret);
       ^

vim +/if +323 fs/ext4/orphan.c

bf840f6979494a Jan Kara 2021-07-12  290  
bf840f6979494a Jan Kara 2021-07-12  291  	while (es->s_last_orphan) {
bf840f6979494a Jan Kara 2021-07-12  292  		struct inode *inode;
bf840f6979494a Jan Kara 2021-07-12  293  
bf840f6979494a Jan Kara 2021-07-12  294  		/*
bf840f6979494a Jan Kara 2021-07-12  295  		 * We may have encountered an error during cleanup; if
bf840f6979494a Jan Kara 2021-07-12  296  		 * so, skip the rest.
bf840f6979494a Jan Kara 2021-07-12  297  		 */
bf840f6979494a Jan Kara 2021-07-12  298  		if (EXT4_SB(sb)->s_mount_state & EXT4_ERROR_FS) {
bf840f6979494a Jan Kara 2021-07-12  299  			jbd_debug(1, "Skipping orphan recovery on fs with errors.\n");
bf840f6979494a Jan Kara 2021-07-12  300  			es->s_last_orphan = 0;
bf840f6979494a Jan Kara 2021-07-12  301  			break;
bf840f6979494a Jan Kara 2021-07-12  302  		}
bf840f6979494a Jan Kara 2021-07-12  303  
bf840f6979494a Jan Kara 2021-07-12  304  		inode = ext4_orphan_get(sb, le32_to_cpu(es->s_last_orphan));
bf840f6979494a Jan Kara 2021-07-12  305  		if (IS_ERR(inode)) {
bf840f6979494a Jan Kara 2021-07-12  306  			es->s_last_orphan = 0;
bf840f6979494a Jan Kara 2021-07-12  307  			break;
bf840f6979494a Jan Kara 2021-07-12  308  		}
bf840f6979494a Jan Kara 2021-07-12  309  
bf840f6979494a Jan Kara 2021-07-12  310  		list_add(&EXT4_I(inode)->i_orphan, &EXT4_SB(sb)->s_orphan);
bf840f6979494a Jan Kara 2021-07-12  311  		dquot_initialize(inode);
bf840f6979494a Jan Kara 2021-07-12  312  		if (inode->i_nlink) {
bf840f6979494a Jan Kara 2021-07-12  313  			if (test_opt(sb, DEBUG))
bf840f6979494a Jan Kara 2021-07-12  314  				ext4_msg(sb, KERN_DEBUG,
bf840f6979494a Jan Kara 2021-07-12  315  					"%s: truncating inode %lu to %lld bytes",
bf840f6979494a Jan Kara 2021-07-12  316  					__func__, inode->i_ino, inode->i_size);
bf840f6979494a Jan Kara 2021-07-12  317  			jbd_debug(2, "truncating inode %lu to %lld bytes\n",
bf840f6979494a Jan Kara 2021-07-12  318  				  inode->i_ino, inode->i_size);
bf840f6979494a Jan Kara 2021-07-12  319  			inode_lock(inode);
bf840f6979494a Jan Kara 2021-07-12  320  			truncate_inode_pages(inode->i_mapping, inode->i_size);
bf840f6979494a Jan Kara 2021-07-12  321  			ret = ext4_truncate(inode);
bf840f6979494a Jan Kara 2021-07-12  322  			if (ret)
bf840f6979494a Jan Kara 2021-07-12 @323  				ext4_std_error(inode->i_sb, ret);
bf840f6979494a Jan Kara 2021-07-12  324  			inode_unlock(inode);
bf840f6979494a Jan Kara 2021-07-12  325  			nr_truncates++;
bf840f6979494a Jan Kara 2021-07-12  326  		} else {
bf840f6979494a Jan Kara 2021-07-12  327  			if (test_opt(sb, DEBUG))
bf840f6979494a Jan Kara 2021-07-12  328  				ext4_msg(sb, KERN_DEBUG,
bf840f6979494a Jan Kara 2021-07-12  329  					"%s: deleting unreferenced inode %lu",
bf840f6979494a Jan Kara 2021-07-12  330  					__func__, inode->i_ino);
bf840f6979494a Jan Kara 2021-07-12  331  			jbd_debug(2, "deleting unreferenced inode %lu\n",
bf840f6979494a Jan Kara 2021-07-12  332  				  inode->i_ino);
bf840f6979494a Jan Kara 2021-07-12  333  			nr_orphans++;
bf840f6979494a Jan Kara 2021-07-12  334  		}
bf840f6979494a Jan Kara 2021-07-12  335  		iput(inode);  /* The delete magic happens here! */
bf840f6979494a Jan Kara 2021-07-12  336  	}
bf840f6979494a Jan Kara 2021-07-12  337  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

^ permalink raw reply	[flat|nested] 8+ messages in thread
* [PATCH 0/5 v7] ext4: Speedup orphan file handling
@ 2021-08-16  9:57 Jan Kara
  2021-08-16  9:57 ` [PATCH 2/5] ext4: Move orphan inode handling into a separate file Jan Kara
  0 siblings, 1 reply; 8+ messages in thread
From: Jan Kara @ 2021-08-16  9:57 UTC (permalink / raw)
  To: Ted Tso; +Cc: linux-ext4, Jan Kara

  Hello,

Here is the seventh version of my series to speed up orphan inode handling in
ext4. I've forgot to add a check that orphan file is not exposed in directory
hierarchy. The only change in this version is addition of that fix.

Orphan inode handling in ext4 is a bottleneck for workloads which heavily
excercise truncate / unlink of small files as they contend on global
s_orphan_mutex (when you have fast enough storage). This patch set implements
new way of handling orphan inodes - instead of using a linked list, we store
inode numbers of orphaned inodes in a file which is possible to implement in a
more scalable manner than linked list manipulations. See description of patch
3/5 for more details.

The patch set achieves significant gains both for a micro benchmark stressing
orphan inode handling (truncating file byte-by-byte, several threads in
parallel) and for reaim creat_clo workload. I'm happy for any review, thoughts,
ideas about the patches. I have also implemented full support in e2fsprogs
which I'll send separately.

								Honza

[1] https://lore.kernel.org/lkml/20210227120804.GB22871@xsang-OptiPlex-9020/

Changes since v6:
* Rebased on top of v5.14-rc6 + patches fixing exposure of hidden inodes in
  directory hierarchy
* Added check orphan file cannot be linked from directory hierarchy
* Get orphan file inode with EXT4_IGET_SPECIAL flag

Changes since v5:
* Added Reviewed-by tags from Ted
* Fixed up sparse warning spotted by 0-day
* Fixed error handling path in ext4_orphan_add() to not leak orphan entry

Changes since v4:
* Rebased on top of v5.14-rc5
* Updated commit message of patch 1/5
* Added Reviewed-by tags from Ted

Changes since v3:
* Added documentation about on-disk format changes
* Add physical block number into orphan block checksum
* Improve some sanity checks, handling of corrupted orphan file
* Improved some changelogs

Changes since v2:
* Updated some comments
* Rebased onto 5.13-rc5
* Change orphan file inode from a fixed inode number to inode number stored
  in the superblock

Changes since v1:
* orphan blocks have now magic numbers
* split out orphan handling to a separate source file
* some smaller updates according to review

Previous versions:
Link: http://lore.kernel.org/r/20210816091810.16994-1-jack@suse.cz # v6
Link: http://lore.kernel.org/r/20210811101006.2033-1-jack@suse.cz # v5
Link: https://lore.kernel.org/linux-ext4/20210712154009.9290-1-jack@suse.cz/ #v4
Link: https://lore.kernel.org/linux-ext4/20210616105655.5129-1-jack@suse.cz/ #v3
Link: https://lore.kernel.org/linux-ext4/1432293717-24010-1-git-send-email-jack@suse.cz/ #v2

^ permalink raw reply	[flat|nested] 8+ messages in thread
* [PATCH 0/5 v6] ext4: Speedup orphan file handling
@ 2021-08-16  9:22 Jan Kara
  2021-08-16  9:23 ` [PATCH 2/5] ext4: Move orphan inode handling into a separate file Jan Kara
  0 siblings, 1 reply; 8+ messages in thread
From: Jan Kara @ 2021-08-16  9:22 UTC (permalink / raw)
  To: Ted Tso; +Cc: linux-ext4, Jan Kara

  Hello,

Here is a fourth version of my series to speed up orphan inode handling in
ext4.

Orphan inode handling in ext4 is a bottleneck for workloads which heavily
excercise truncate / unlink of small files as they contend on global
s_orphan_mutex (when you have fast enough storage). This patch set implements
new way of handling orphan inodes - instead of using a linked list, we store
inode numbers of orphaned inodes in a file which is possible to implement in a
more scalable manner than linked list manipulations. See description of patch
3/5 for more details.

The patch set achieves significant gains both for a micro benchmark stressing
orphan inode handling (truncating file byte-by-byte, several threads in
parallel) and for reaim creat_clo workload. I'm happy for any review, thoughts,
ideas about the patches. I have also implemented full support in e2fsprogs
which I'll send separately.

								Honza

[1] https://lore.kernel.org/lkml/20210227120804.GB22871@xsang-OptiPlex-9020/

Changes since v5:
* Added Reviewed-by tags from Ted
* Fixed up sparse warning spotted by 0-day
* Fixed error handling path in ext4_orphan_add() to not leak orphan entry

Changes since v4:
* Rebased on top of v5.14-rc5
* Updated commit message of patch 1/5
* Added Reviewed-by tags from Ted

Changes since v3:
* Added documentation about on-disk format changes
* Add physical block number into orphan block checksum
* Improve some sanity checks, handling of corrupted orphan file
* Improved some changelogs

Changes since v2:
* Updated some comments
* Rebased onto 5.13-rc5
* Change orphan file inode from a fixed inode number to inode number stored
  in the superblock

Changes since v1:
* orphan blocks have now magic numbers
* split out orphan handling to a separate source file
* some smaller updates according to review

Previous versions:
Link: http://lore.kernel.org/r/20210811101006.2033-1-jack@suse.cz # v5
Link: https://lore.kernel.org/linux-ext4/20210712154009.9290-1-jack@suse.cz/ #v4
Link: https://lore.kernel.org/linux-ext4/20210616105655.5129-1-jack@suse.cz/ #v3
Link: https://lore.kernel.org/linux-ext4/1432293717-24010-1-git-send-email-jack@suse.cz/ #v2

^ permalink raw reply	[flat|nested] 8+ messages in thread
* [PATCH 0/5 v5] ext4: Speedup orphan file handling
@ 2021-08-11 10:19 Jan Kara
  2021-08-11 10:19 ` [PATCH 2/5] ext4: Move orphan inode handling into a separate file Jan Kara
  0 siblings, 1 reply; 8+ messages in thread
From: Jan Kara @ 2021-08-11 10:19 UTC (permalink / raw)
  To: Ted Tso; +Cc: linux-ext4, Jan Kara

  Hello,

Here is a fourth version of my series to speed up orphan inode handling in
ext4.

Orphan inode handling in ext4 is a bottleneck for workloads which heavily
excercise truncate / unlink of small files as they contend on global
s_orphan_mutex (when you have fast enough storage). This patch set implements
new way of handling orphan inodes - instead of using a linked list, we store
inode numbers of orphaned inodes in a file which is possible to implement in a
more scalable manner than linked list manipulations. See description of patch
3/5 for more details.

The patch set achieves significant gains both for a micro benchmark stressing
orphan inode handling (truncating file byte-by-byte, several threads in
parallel) and for reaim creat_clo workload. I'm happy for any review, thoughts,
ideas about the patches. I have also implemented full support in e2fsprogs
which I'll send separately.

								Honza

[1] https://lore.kernel.org/lkml/20210227120804.GB22871@xsang-OptiPlex-9020/

Changes since v4:
* Rebased on top of v5.14-rc5
* Updated commit message of patch 1/5
* Added Reviewed-by tags from Ted

Changes since v3:
* Added documentation about on-disk format changes
* Add physical block number into orphan block checksum
* Improve some sanity checks, handling of corrupted orphan file
* Improved some changelogs

Changes since v2:
* Updated some comments
* Rebased onto 5.13-rc5
* Change orphan file inode from a fixed inode number to inode number stored
  in the superblock

Changes since v1:
* orphan blocks have now magic numbers
* split out orphan handling to a separate source file
* some smaller updates according to review

Previous versions:
Link: https://lore.kernel.org/linux-ext4/20210712154009.9290-1-jack@suse.cz/ #v4
Link: https://lore.kernel.org/linux-ext4/20210616105655.5129-1-jack@suse.cz/ #v3
Link: https://lore.kernel.org/linux-ext4/1432293717-24010-1-git-send-email-jack@suse.cz/ #v2

^ permalink raw reply	[flat|nested] 8+ messages in thread
* [PATCH 0/5 v4] ext4: Speedup orphan file handling
@ 2021-07-12 15:40 Jan Kara
  2021-07-12 15:40 ` [PATCH 2/5] ext4: Move orphan inode handling into a separate file Jan Kara
  0 siblings, 1 reply; 8+ messages in thread
From: Jan Kara @ 2021-07-12 15:40 UTC (permalink / raw)
  To: Ted Tso; +Cc: linux-ext4, Jan Kara

  Hello,

Here is a fourth version of my series to speed up orphan inode handling in
ext4.

Orphan inode handling in ext4 is a bottleneck for workloads which heavily
excercise truncate / unlink of small files as they contend on global
s_orphan_mutex (when you have fast enough storage). This patch set implements
new way of handling orphan inodes - instead of using a linked list, we store
inode numbers of orphaned inodes in a file which is possible to implement in a
more scalable manner than linked list manipulations. See description of patch
3/5 for more details.

The patch set achieves significant gains both for a micro benchmark stressing
orphan inode handling (truncating file byte-by-byte, several threads in
parallel) and for reaim creat_clo workload. I'm happy for any review, thoughts,
ideas about the patches. I have also implemented full support in e2fsprogs
which I'll send separately.

								Honza

[1] https://lore.kernel.org/lkml/20210227120804.GB22871@xsang-OptiPlex-9020/

Changes since v3:
* Added documentation about on-disk format changes
* Add physical block number into orphan block checksum
* Improve some sanity checks, handling of corrupted orphan file
* Improved some changelogs

Changes since v2:
* Updated some comments
* Rebased onto 5.13-rc5
* Change orphan file inode from a fixed inode number to inode number stored
  in the superblock

Changes since v1:
* orphan blocks have now magic numbers
* split out orphan handling to a separate source file
* some smaller updates according to review

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2021-08-16  9:57 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-13  4:49 [PATCH 2/5] ext4: Move orphan inode handling into a separate file kernel test robot
  -- strict thread matches above, loose matches on Subject: below --
2021-08-16  9:57 [PATCH 0/5 v7] ext4: Speedup orphan file handling Jan Kara
2021-08-16  9:57 ` [PATCH 2/5] ext4: Move orphan inode handling into a separate file Jan Kara
2021-08-16  9:22 [PATCH 0/5 v6] ext4: Speedup orphan file handling Jan Kara
2021-08-16  9:23 ` [PATCH 2/5] ext4: Move orphan inode handling into a separate file Jan Kara
2021-08-11 10:19 [PATCH 0/5 v5] ext4: Speedup orphan file handling Jan Kara
2021-08-11 10:19 ` [PATCH 2/5] ext4: Move orphan inode handling into a separate file Jan Kara
2021-07-12 15:40 [PATCH 0/5 v4] ext4: Speedup orphan file handling Jan Kara
2021-07-12 15:40 ` [PATCH 2/5] ext4: Move orphan inode handling into a separate file Jan Kara
2021-07-22 14:53   ` Theodore Ts'o
2021-08-08 14:29   ` Theodore Ts'o
2021-08-10 13:15     ` Jan Kara

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.