On 2019/4/16 上午12:27, David Sterba wrote: > On Thu, Apr 11, 2019 at 01:54:44PM +0800, Qu Wenruo wrote: >> Here is my pull request for the btrfs-progs: >> https://github.com/adam900710/btrfs-progs/tree/for_devel >> >> The basis is the following commit from your devel branch: >> commit a8389337c5a0e7c3fb32ff91d557889c036da73a >> Author: Adam Borowski <kilobyte@xxxxxxxxxx> >> Date: Mon Feb 25 19:16:44 2019 +0100 >> >> btrfs-progs: defrag: open files RO on new enough kernels > > Please rebase the branch on top of current devel, with "btrfs-progs: > Remove get_argv0_buf". I had a few patches merged but the branch was not > public so there's some duplication. > >> This branch drops the following commit in your devel branch: >> commit 4e8eb31f048f3fe9a68aacb58e4c0714df25b5c4 (david/devel) >> Author: Qu Wenruo <wqu@xxxxxxxx> >> Date: Fri Sep 14 15:49:44 2018 +0800 >> >> btrfs-progs: Do metadata preallocation as long as we're not >> modifying extent tree > > This fixes issue #123, is there another fix? Not yet, the reason is known but new fix is still under development. Discarding it at least won't cause new problem. >I'll drop the patch from > devel as it fails the test so the revert won't be needed. > >> Due to test failure on looping chunk allocation. >> >> The branch passes all selftests, except misc/035 which is a known problem. >> >> This pull request include the following features: >> >> Core change: >> - check --repair >> * Flush/FUA support to avoid breaking metadata CoW >> Now btrfs-progs crashing or transaction aborted won't cause >> new transid error. >> - device scan: >> * Add the ability to forget a device >> >> Fixes and Enhancement: >> - generic >> * Try best copy when reading tree blocks. >> * Skip unnecessary retry when one tree block copy fails. >> * Avoid back tree block to populate tree block cache. >> - check >> * File extents repair no longer relies data in extent tree. >> * New ability to check and repair free space cache invalid inode mode. >> * Update backup roots when commit transaction. >> - mkfs: >> * Enlarge metadata chunk size to follow kernel size. >> - defrag >> * open file in RO for newer kernel. >> - gitignore >> * Ignore hidden files. >> - qgroup report >> * Handle unrecognized sort string. >> - receive >> * New quite mode. >> - Misc >> * More cleanup for fs_info <-> root parameters. > > Nice, I'll put it to the merge commit once the branch is ready. > [snip] >> btrfs-progs: qgroup show: report errors while parsing sort string >> btrfs-progs: qgroup show: report unrecognized format of sort string >> btrfs-progs: qgoup: propagate errors from >> btrfs_qgroup_parse_sort_string > > For pull-based workflows there are some things that I'd require, based > on what I do for kernel patches, so let's use this one to set the > expectations: > > The excerpt above from the shortlog (and other commits) was not intended > to be pulled, so it should not be in the shortlog. Got it. > > Please note that all patches need to have signed-off-by by the > committer. This is not true for Just one minor question, if I'm the author, no need for another SoB line right? > > - btrfs-progs: fsck-test: enable lowmem repair for case 001 > - btrfs-progs: tests: add case for inode lose one file extent > > The commits that do revert do not need the 'btrfs-progs:' prefix, > without it it's obvious in the patch subject list that those are > exceptions. > > One thing that I edit in almost all commit is the order of tags, briefly > documented at > https://btrfs.wiki.kernel.org/index.php/Developer%27s_FAQ#Ordering Oh, this is indeed different from my understand. Especially for the reviewed-by and tested-by tags. I'll definitely reorder those in next update. Thanks, Qu > > I don't require a signed tag to pull as the amount of pull requests is > not going to be high, review is feasible for me. > > One thing that might be new for you is that you'll be the first get > blamed for everything what's in the branch you send to pull, then the > original authors :) It's good to favor quality over quantity. > > There's probably more of lower importance, we'll find out along the way. >
Attachment:
signature.asc
Description: OpenPGP digital signature
