Re: [PATCH] fstests: common: Enhance _exclude_scratch_mount_option to handle multiply options and generic fs type

On Tue, Sep 06, 2016 at 01:06:39PM +0800, Qu Wenruo wrote: > Considering not every contributor will add comment about excluded > mount options, and in case generic test cases needs to exclude one > mount option for given fstype, it will be quite hard to find the > reason. That is why we review

Re: [PATCH] fstests: common: Enhance _exclude_scratch_mount_option to handle multiply options and generic fs type

On Tue, Sep 06, 2016 at 12:20:39PM +0800, Eryu Guan wrote: > On Mon, Sep 05, 2016 at 03:13:33PM +0800, Qu Wenruo wrote: > > Enhance _exclude_scratch_mount_option() function to get real mount > > options from $MOUNT_OPTIONS. > > This seems unnecessarily complex to me. > > > > > Now it can

Re: [PATCH] fstests: common: Enhance _exclude_scratch_mount_option to handle multiply options and generic fs type

On Tue, Sep 06, 2016 at 01:06:39PM +0800, Qu Wenruo wrote: > > > At 09/06/2016 12:20 PM, Eryu Guan wrote: > > On Mon, Sep 05, 2016 at 03:13:33PM +0800, Qu Wenruo wrote: > > > Enhance _exclude_scratch_mount_option() function to get real mount > > > options from $MOUNT_OPTIONS. > > > > This seems

[PATCH] btrfs-progs: qgroup: Fix regression leads to corrupted qgroup status

Commit 93dabf211d74daf6e3de642bdd887a90a00f7b49 Author: Mark Fasheh Date: Fri Jun 17 13:37:48 2016 -0700 btrfs-progs: check: verify qgroups above level 0 This commit introduced a new regression which corrupts read_qgroup_status, since it iterate leaf with manually

Re: [PATCH] Btrfs: remove unnecessary code of chunk_root assignment in btrfs_read_chunk_tree.

At 09/07/2016 09:38 AM, Sean Fu wrote: On Mon, Sep 05, 2016 at 03:56:41PM +0800, Qu Wenruo wrote: At 09/05/2016 09:19 AM, Zhao Lei wrote: Hi, Sean Fu From: Sean Fu [mailto:fxinr...@gmail.com] Sent: Sunday, September 04, 2016 7:54 PM To: dste...@suse.com Cc: c...@fb.com;

Re: [PATCH] Btrfs: remove unnecessary code of chunk_root assignment in btrfs_read_chunk_tree.

On Tue, Sep 06, 2016 at 11:12:20AM -0400, Jeff Mahoney wrote: > On 9/6/16 5:58 AM, David Sterba wrote: > > On Mon, Sep 05, 2016 at 11:13:40PM -0400, Jeff Mahoney wrote: > Since root is only used to get fs_info->chunk_root, why not use fs_info > directly? > >>> > >>> Weird. Exactly this

Re: [PATCH v2] Btrfs: remove unnecessary code of chunk_root assignment in btrfs_read_chunk_tree.

On Tue, Sep 06, 2016 at 01:19:39PM +0800, Zhao Lei wrote: > Hi, Sean Fu > > > -Original Message- > > From: Sean Fu [mailto:fxinr...@gmail.com] > > Sent: Tuesday, September 06, 2016 11:51 AM > > To: dste...@suse.com > > Cc: c...@fb.com; anand.j...@oracle.com; fdman...@suse.com; > >

Re: [PATCH] Btrfs: remove unnecessary code of chunk_root assignment in btrfs_read_chunk_tree.

On Mon, Sep 05, 2016 at 03:56:41PM +0800, Qu Wenruo wrote: > > > At 09/05/2016 09:19 AM, Zhao Lei wrote: > >Hi, Sean Fu > > > >>From: Sean Fu [mailto:fxinr...@gmail.com] > >>Sent: Sunday, September 04, 2016 7:54 PM > >>To: dste...@suse.com > >>Cc: c...@fb.com; anand.j...@oracle.com;

Re: Recommendation on raid5 drive error resolution

Things have been copying off really well. I'm starting to suspect the issue was the PSU which I've swapped out. What is the line I should see in dmesg if the degraded option was actually used when mounting the file system? On Thu, Sep 1, 2016 at 9:25 PM, Austin S. Hemmelgarn

[PATCH 1/3] btrfs-progs: Introduce new send-dump object

Introduce send-dump.[ch] which implements a new btrfs_send_ops to exam and output all operations inside a send stream. It has a better output format than the old and no longer compilable send-test tool, but still tries to be script friendly. Provides the basis for later "inspect-internal

[PATCH 3/3] btrfs-progs: Remove send-test tool

Since new "receive --dump" has better output and structure, it's time to remove old and function-weak send-test tool. Signed-off-by: Qu Wenruo --- Makefile.in | 6 +- send-test.c | 447 2 files changed, 1

[PATCH v2 2/3] btrfs-progs: receive: Introduce option to exam and dump send stream

Introduce new option, '--dump' for receive subcommand. With this command, user can exam and dump the metadata info of a send stream. Which is quite useful for education purpose or bug reporting. Signed-off-by: Qu Wenruo --- Documentation/btrfs-receive.asciidoc | 17

[PATCH 0/3] Introduce dump option for btrfs-receive

Introduce new "--dump" option for btrfs-receive, which will exam and dump metadata info of a send stream. This is quite handy to debug send stream. Since such function is provided by old send-test tool, which doesn't even compile now, remove the old send-test tool. changelog: v2: Move from

Re: btrfs send extremely slow (almost stuck)

Duncan wrote on Mon, 05 Sep 2016 19:14:30 -0700: > I had something very similar happen here a few weeks ago, except with my > firefox profile dir (I don't run thunderbird, preferring claws-mail, but > I do run firefox as my browser). Indeed, I also note Firefox doing a lot of IO especially if

Re: [PATCH 7/7] Btrfs: fix memory leak due to invalid btree height

On Tue, Sep 06, 2016 at 06:50:19PM +0200, David Sterba wrote: > On Fri, May 13, 2016 at 05:07:02PM -0700, Liu Bo wrote: > > Thanks to fuzz testing, we can have invalid btree root node height. > > Shouldn't we do this kind of sanity checks earlier? Not at the search > slot time but when it's read

Re: btrfs send extremely slow (almost stuck)

Am 06.09.2016 um 04:46 schrieb Qu Wenruo: > But your idea to locate the inode seems good enough for debugging though. Based on this I even had another idea which seems to have worked well - and I am now also able to provide any additional debug output you may need. Since my procedure may be

Re: [PATCH] Btrfs: fix BUG_ON in btrfs_mark_buffer_dirty

Hi Filipe, On Mon, Sep 05, 2016 at 04:28:09PM +0100, Filipe Manana wrote: > On Fri, Sep 2, 2016 at 8:35 PM, Liu Bo wrote: > > This can only happen with CONFIG_BTRFS_FS_CHECK_INTEGRITY=y. > > > > Commit 1ba98d0 ("Btrfs: detect corruption when non-root leaf has zero item") >

State of the fuzzer

Hi, I'm currently fuzzing rev 2076992 and things start to slowly, slowly quiet down. We will probably run out of steam at the end of the week when a total of (roughly) half a billion BTRFS-images have passed by. I will switch revisions to current HEAD and restart the whole process then. A few

Re: [PATCH] Btrfs: don't leak reloc root nodes on errorg

On Mon, Sep 05, 2016 at 05:20:53PM +0200, David Sterba wrote: > On Fri, Sep 02, 2016 at 06:08:35PM -0700, Liu Bo wrote: > > On Fri, Sep 02, 2016 at 03:25:43PM -0400, Josef Bacik wrote: > > > We don't track the reloc roots in any sort of normal way, so the only way > > > the > > > root/commit_root

Re: [OT] ccache and tmpfs builds Was: Balancing subvolume on a specific device

Austin S. Hemmelgarn posted on Tue, 06 Sep 2016 08:32:02 -0400 as excerpted: > On 2016-09-02 06:55, Duncan wrote: >> Kai Krakow posted on Thu, 01 Sep 2016 21:45:19 +0200 as excerpted: >> >>> Off topic: Is ccache really that helpful? I dumped it a few years ago >>> What would help a whole lot

Re: [PATCH 15/31] btrfs: call functions that overwrite their root parameter with fs_info

Hi, On Fri, Jun 24, 2016 at 06:15:08PM -0400, je...@suse.com wrote: > From: Jeff Mahoney > > There are 11 functions that accept a root parameter and immediately > overwrite it. We can pass those an fs_info pointer instead. > > Signed-off-by: Jeff Mahoney

Re: [PATCH] btrfs: fix WARNING in btrfs_select_ref_head()

Josef, can you please review this? On Mon, Jun 20, 2016 at 09:18:52AM +0800, Wang Xiaoguang wrote: > This issue was found when testing in-band dedupe enospc behaviour, > sometimes run_one_delayed_ref() may fail for enospc reason, then > __btrfs_run_delayed_refs（）will return, but forget to add

Re: Security implications of btrfs receive?

Thanks to Austin and Duncan for their replies. On 06/09/16 13:15, Austin S. Hemmelgarn wrote: > On 2016-09-05 05:59, Graham Cobb wrote: >> Does the "path" argument of btrfs-receive mean that *all* operations are >> confined to that path? For example, if a UUID or transid is sent which >> refers

Re: [PATCH 7/7] Btrfs: fix memory leak due to invalid btree height

On Fri, May 13, 2016 at 05:07:02PM -0700, Liu Bo wrote: > Thanks to fuzz testing, we can have invalid btree root node height. Shouldn't we do this kind of sanity checks earlier? Not at the search slot time but when it's read from disk. The check that you're adding can stay, but without the early

Re: [PATCH 2/2] btrfs-progs: Doc: Add warning for build RAID btrfs on partions from the same device

On Fri, Sep 02, 2016 at 09:41:45AM +0800, Qu Wenruo wrote: > Quite a common sense for any RAID-like multi-device setup, just in case. > > Signed-off-by: Qu Wenruo Both applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body

Some help with the code.

This is predominantly for maintainers: I've noticed that there is a lot of code for btrfs ... and after few glimpses I've noticed that there are occurrences which beg for some refactoring to make it less of a pain to maintain. I'm speaking of occurrences where: - within a function there are

Re: [PATCH]btrfs-progs: Post btrfs-convert verify permissions and acls

On Mon, Sep 05, 2016 at 09:27:36PM +0200, Lakshmipathi.G wrote: > Signed-off-by: Lakshmipathi.G Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: [PATCH] Btrfs: remove unnecessary code of chunk_root assignment in btrfs_read_chunk_tree.

On 9/6/16 5:58 AM, David Sterba wrote: > On Mon, Sep 05, 2016 at 11:13:40PM -0400, Jeff Mahoney wrote: Since root is only used to get fs_info->chunk_root, why not use fs_info directly? >>> >>> Weird. Exactly this was a part of my fs_info patchset. I guess I need >>> to go back and

Re: [PATCH 02/13] btrfs-progs: check: introduce function to find dir_item

On Thu, Jul 28, 2016 at 03:08:14PM +0800, Lu Fengqi wrote: > +static int find_dir_item(struct btrfs_root *root, struct btrfs_key *ref_key, > + struct btrfs_key *key, u64 index, char *name, > + u32 namelen, u32 mode) > +{ > + struct btrfs_path *path; >

[PATCH] Btrfs: remove root_log_ctx from ctx list before btrfs_sync_log returns

We use a btrfs_log_ctx structure to pass information into the tree log commit, and get error values out. It gets added to a per log-transaction list which we walk when things go bad. Commit d1433debe added an optimization to skip waiting for the log commit, but didn't take root_log_ctx out of

Re: [PATCH 0/7] Kill the btree inode

On 09/05/2016 12:31 PM, David Sterba wrote: On Fri, Sep 02, 2016 at 03:39:59PM -0400, Josef Bacik wrote: In order to provide a better way to do subpage blocksizes we need to stop allocating pages from a per fs btree inode and instead allocate our own pages. This work depends on 3 generic

Re: [PATCH] btrfs: let btrfs_delete_unused_bgs() to clean relocated bgs

On 09/05/2016 12:32 AM, Naohiro Aota wrote: 2016-09-02 (金) の 09:35 -0400 に Josef Bacik さんは書きました: On 09/02/2016 03:46 AM, Naohiro Aota wrote: Currently, btrfs_relocate_chunk() is removing relocated BG by itself. But the work can be done by btrfs_delete_unused_bgs() (and it's better since it

Re: [PATCH] btrfs: introduce tickets_id to determine whether asynchronous metadata reclaim work makes progress

On 09/06/2016 06:18 AM, Wang Xiaoguang wrote: hello, On 09/02/2016 09:28 PM, Josef Bacik wrote: On 09/01/2016 10:58 PM, Wang Xiaoguang wrote: In btrfs_async_reclaim_metadata_space(), we use ticket's address to determine whether asynchronous metadata reclaim work is making progress.

Re: [OT] Re: Balancing subvolume on a specific device

On 2016-09-02 06:55, Duncan wrote: Kai Krakow posted on Thu, 01 Sep 2016 21:45:19 +0200 as excerpted: Am Sat, 20 Aug 2016 06:30:11 + (UTC) schrieb Duncan <1i5t5.dun...@cox.net>: There's at least three other options to try to get what you mention, however. FWIW, I'm a gentooer and thus

Re: Security implications of btrfs receive?

On 2016-09-05 05:59, Graham Cobb wrote: Does anyone know of a security analysis of btrfs receive? I'm not a developer, and definitely not a security specialist, just a security minded sysadmin who has some idea what's going on, but I can at least try and answer this. I assume that just using

Re: [PATCH] btrfs: introduce tickets_id to determine whether asynchronous metadata reclaim work makes progress

hello, On 09/02/2016 09:28 PM, Josef Bacik wrote: On 09/01/2016 10:58 PM, Wang Xiaoguang wrote: In btrfs_async_reclaim_metadata_space(), we use ticket's address to determine whether asynchronous metadata reclaim work is making progress. ticket = list_first_entry(_info->tickets,

Re: [PATCH] Btrfs: remove unnecessary code of chunk_root assignment in btrfs_read_chunk_tree.

On Mon, Sep 05, 2016 at 11:13:40PM -0400, Jeff Mahoney wrote: > >> Since root is only used to get fs_info->chunk_root, why not use fs_info > >> directly? > > > > Weird. Exactly this was a part of my fs_info patchset. I guess I need > > to go back and check what else is missing. > > Actually,