Re: USB upgrade fun

At Sun, 08 Oct 2017 17:58:10 +0800, Kai Hendry wrote: > > Hi there, > > My /mnt/raid1 suddenly became full somewhat expectedly, so I bought 2 > new USB 4TB hard drives (one WD, one Seagate) to upgrade to. > > After adding sde and sdd I started to see errors in dmesg [2]. >

[PATCHSET] cgroup, writeback, btrfs: make sure btrfs issues metadata IOs from the root cgroup

Hello, btrfs has different ways to issue metadata IOs and may end up issuing metadata or otherwise shared IOs from a non-root cgroup, which can lead to priority inversion and ineffective IO isolation. This patchset makes sure that btrfs issues all metadata and shared IOs from the root cgroup by

[PATCH 2/3] cgroup, writeback: implement submit_bh_blkcg_css()

Add wbc->blkcg_css so that the blkcg_css association can be specified independently and implement submit_bh_blkcg_css() using it. This will be used to override cgroup membership on specific buffer_heads. Signed-off-by: Tejun Heo Cc: Jan Kara Cc: Jens Axboe

[PATCH 1/3] cgroup, writeback: replace SB_I_CGROUPWB with per-inode S_CGROUPWB

Currently, filesystem can indiate cgroup writeback support per superblock; however, depending on the filesystem, especially if inodes are used to carry metadata, it can be useful to indicate cgroup writeback support per inode. This patch replaces the superblock flag SB_I_CGROUPWB with per-inode

[PATCH 3/3] btrfs: ensure that metadata and flush are issued from the root cgroup

Issuing metdata or otherwise shared IOs from !root cgroup can lead to priority inversion. This patch ensures that those IOs are always issued from the root cgroup. This patch updates btrfs_update_iflags() to not set S_CGROUPWB on btree_inodes. This isn't strictly necessary as those inodes don't

Re: [ANNOUNCE] fsperf: a simple fs/block performance testing framework

On Tue, Oct 10, 2017 at 08:09:20AM +1100, Dave Chinner wrote: > On Mon, Oct 09, 2017 at 09:00:51AM -0400, Josef Bacik wrote: > > On Mon, Oct 09, 2017 at 04:17:31PM +1100, Dave Chinner wrote: > > > On Sun, Oct 08, 2017 at 10:25:10PM -0400, Josef Bacik wrote: > > > > > Integrating into fstests means

Re: [ANNOUNCE] fsperf: a simple fs/block performance testing framework

On Mon, Oct 09, 2017 at 09:00:51AM -0400, Josef Bacik wrote: > On Mon, Oct 09, 2017 at 04:17:31PM +1100, Dave Chinner wrote: > > On Sun, Oct 08, 2017 at 10:25:10PM -0400, Josef Bacik wrote: > > > > Integrating into fstests means it will be immediately available to > > > > all fs developers, it'll

[PATCH] Btrfs: avoid losing data raid profile when deleting a device

We've avoided data losing raid profile when doing balance, but it turns out that deleting a device could also result in the same problem. This fixes the problem by creating an empty data chunk before relocating the data chunk. Metadata/System chunk are supposed to have non-zero bytes all the

[PATCH] Fstest: btrfs/151: test if device delete ends up with losing raid profile

Currently running 'btrfs device delete' can end up with losing data raid profile (if any), this test is to reproduce the problem. The fix is "Btrfs: avoid losing data raid profile when deleting a device" Signed-off-by: Liu Bo --- tests/btrfs/151 | 73

Re: Why do full balance and deduplication reduce available free space?

Am Mon, 02 Oct 2017 22:19:32 +0200 schrieb Niccolò Belli : > Il 2017-10-02 21:35 Kai Krakow ha scritto: > > Besides defragging removing the reflinks, duperemove will unshare > > your snapshots when used in this way: If it sees duplicate blocks > > within the subvolumes

WARNING: ... at fs/btrfs/ctree.h:1559 btrfs_update_device+0x1be/0x1d0 [btrfs]

Hi, I update kernel from 4.11.10 to 4.13.4 and since that I get the following message in the kernel journal calling 'scrub' or 'balance'. I use Fedora 26 with btrfs-progs v4.9.1. What does this mean and (more important) what can I do? Bye Frank BTRFS info (device dm-7): relocating

Re: [PATCH] btrfs: prefix sysfs attribute struct names

On Sun, Oct 08, 2017 at 10:30:58PM +0200, Hans van Kranenburg wrote: > Currently struct names for sysfs are generated only based on the > attribute names. This means that attribute names cannot be reused in > multiple places throughout the complete btrfs sysfs hierarchy. > > E.g.

Re: [PATCH] btrfs: Fix bool initialization/comparison

On Sat, Oct 07, 2017 at 04:02:21PM +0200, Thomas Meyer wrote: > Bool initializations should use true and false. Bool tests don't need > comparisons. > > Signed-off-by: Thomas Meyer Reviewed-by: David Sterba -- To unsubscribe from this list: send the line

Re: [PATCH v2] Btrfs: heuristic add shannon entropy calculation

On Sun, Oct 08, 2017 at 04:11:59PM +0300, Timofey Titovets wrote: > Byte distribution check in heuristic will filter edge data > cases and some time fail to classificate input data > > Let's fix that by adding Shannon entropy calculation, > that will cover classification of most other data types.

Re: [PATCH 1/1] Btrfs: heuristic add shannon entropy calculation

On Sat, Oct 07, 2017 at 03:08:26AM +0300, Timofey Titovets wrote: > > I hear the compiler scream, trying to optimize all the ifs. And I think > > the CPU branch prediction would have a hard time, there's practically no > > expected pattern and the performance could be worse compared to the > >

[PATCH v2 2/3] btrfs: rename page offset parameter in submit_extent_page

We're going to remove sector_t and will use 'offset', so this patch frees the name. Reviewed-by: Liu Bo Signed-off-by: David Sterba --- fs/btrfs/extent_io.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/fs/btrfs/extent_io.c

[PATCH v2 1/3] btrfs: scrub: get rid of sector_t

The use of sector_t is not necessry, it's just for a warning. Switch to u64 and rename the variable and use byte units instead of 512b, ie. dropping the >> 9 shifts. The messages are adjusted as well. Reviewed-by: Liu Bo Signed-off-by: David Sterba ---

[PATCH v2 3/3] btrfs: get rid of sector_t and use u64 offset in submit_extent_page

The use of sector_t in the callchain of submit_extent_page is not necessary. Switch to u64 and rename the variable and use byte units instead of 512b, ie. dropping the >> 9 shifts and avoiding the con(tro)versions of sector_t. Reviewed-by: Liu Bo Signed-off-by: David

[PATCH v2 0/3] Cleanup sector_t

v2: - update missing message s/sector/physical/ - updated changelogs where the semantics changed - added reviewed-by David Sterba (3): btrfs: scrub: get rid of sector_t btrfs: rename page offset parameter in submit_extent_page btrfs: get rid of sector_t and use u64 offset in

Re: [ANNOUNCE] fsperf: a simple fs/block performance testing framework

On Mon, Oct 09, 2017 at 08:54:16AM -0400, Josef Bacik wrote: > I purposefully used as little as possible, just json and sqlite, and I tried > to > use as little python3 isms as possible. Any rpm based systems should have > these > libraries already installed, I agree that using any of the PyPI

[PATCH 02/16] btrfs: Use pagevec_lookup_range_tag()

We want only pages from given range in btree_write_cache_pages() and extent_write_cache_pages(). Use pagevec_lookup_range_tag() instead of pagevec_lookup_tag() and remove unnecessary code. CC: linux-btrfs@vger.kernel.org CC: David Sterba Reviewed-by: David Sterba

Re: [ANNOUNCE] fsperf: a simple fs/block performance testing framework

On Fri, Oct 06, 2017 at 05:09:57PM -0400, Josef Bacik wrote: > One thing that comes up a lot every LSF is the fact that we have no general > way > that we do performance testing. Every fs developer has a set of scripts or > things that they run with varying degrees of consistency, but nothing

[PATCH 3.2 24/74] btrfs: Don't clear SGID when inheriting ACLs

3.2.94-rc1 review patch. If anyone has any objections, please let me know. -- From: Jan Kara commit b7f8a09f8097db776b8d160862540e4fc1f51296 upstream. When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit set, DIR1 is expected to have SGID bit

[PATCH 3.16 075/192] btrfs: Don't clear SGID when inheriting ACLs

3.16.49-rc1 review patch. If anyone has any objections, please let me know. -- From: Jan Kara commit b7f8a09f8097db776b8d160862540e4fc1f51296 upstream. When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit set, DIR1 is expected to have SGID

Re: [ANNOUNCE] fsperf: a simple fs/block performance testing framework

On Mon, Oct 09, 2017 at 04:17:31PM +1100, Dave Chinner wrote: > On Sun, Oct 08, 2017 at 10:25:10PM -0400, Josef Bacik wrote: > > On Mon, Oct 09, 2017 at 11:51:37AM +1100, Dave Chinner wrote: > > > On Fri, Oct 06, 2017 at 05:09:57PM -0400, Josef Bacik wrote: > > > > Hello, > > > > > > > > One

Re: [ANNOUNCE] fsperf: a simple fs/block performance testing framework

On Sun, Oct 08, 2017 at 11:43:35PM -0400, Theodore Ts'o wrote: > On Sun, Oct 08, 2017 at 10:25:10PM -0400, Josef Bacik wrote: > > > > Probably should have led with that shouldn't I have? There's nothing > > keeping me > > from doing it, but I didn't want to try and shoehorn in a python thing

Re: [ANNOUNCE] fsperf: a simple fs/block performance testing framework

On Mon, Oct 09, 2017 at 02:54:34PM +0800, Eryu Guan wrote: > I have no problem either if python is really needed, after all this is a > very useful infrastructure improvement. But the python version problem > brought up by Ted made me a bit nervous, we need to work that round > carefully. > >

Re: [PATCH v8 2/2] btrfs: check device for critical errors and mark failed

On 2017-10-06 19:33, Liu Bo wrote: On Thu, Oct 05, 2017 at 07:07:44AM -0400, Austin S. Hemmelgarn wrote: On 2017-10-04 16:11, Liu Bo wrote: On Tue, Oct 03, 2017 at 11:59:20PM +0800, Anand Jain wrote: From: Anand Jain Write and flush errors are critical errors, upon

Re: "BTRFS error (device vda1): couldn't get super buffer head for bytenr x"

On Mon, Oct 9, 2017 at 1:22 AM, Nick Gilmour wrote: >> I don't see a 'btrfs filesystem resize' command in your sequence. Did >> you actually resize the file system before you resized the underlying >> (virtual) block device? > > > OK. I guess, this is it. I didn't do any

Re: [ANNOUNCE] fsperf: a simple fs/block performance testing framework

On Mon, Oct 09, 2017 at 04:17:31PM +1100, Dave Chinner wrote: > On Sun, Oct 08, 2017 at 10:25:10PM -0400, Josef Bacik wrote: > > On Mon, Oct 09, 2017 at 11:51:37AM +1100, Dave Chinner wrote: > > > On Fri, Oct 06, 2017 at 05:09:57PM -0400, Josef Bacik wrote: > > > > Hello, > > > > > > > > One