Re: Input/output error on newly created file

On May 09 2016, Filipe Manana wrote: > On Sun, May 8, 2016 at 11:18 PM, Nikolaus Rath wrote: >> Hello, >> >> I just created an innocent 10 MB on a btrfs file system, yet my attempt >> to read it a few seconds later (and ever since), just gives: >> >> $ ls

Re: [PATCH] btrfs: switch to common message helpers in open_ctree, adjust messages

On 05/09/2016 05:39 PM, David Sterba wrote: Currently we lack the identification of the filesystem in most if not all mount messages, done via printk/pr_* functions. We can use the btrfs_* helpers in open_ctree, as the fs_info <-> sb link is established at the beginning of the function.

Re: Idea on compatibility for old distributions

Mark Fasheh wrote on 2016/05/09 18:52 -0700: On Tue, May 10, 2016 at 09:16:04AM +0800, Qu Wenruo wrote: In the recent test for new btrfs-convert backward compatibility, I found that cmds-fi-du.c uses FIEMAP_EXTENT_SHARED bits, which is not present in kernel of old distributions like RHEL6

Re: Idea on compatibility for old distributions

On Tue, May 10, 2016 at 09:16:04AM +0800, Qu Wenruo wrote: > In the recent test for new btrfs-convert backward compatibility, I > found that cmds-fi-du.c uses FIEMAP_EXTENT_SHARED bits, which is not > present in kernel of old distributions like RHEL6 (Sorry, didn't > test on openSUSE equivalent).

Idea on compatibility for old distributions

Hi David, Mark, In the recent test for new btrfs-convert backward compatibility, I found that cmds-fi-du.c uses FIEMAP_EXTENT_SHARED bits, which is not present in kernel of old distributions like RHEL6 (Sorry, didn't test on openSUSE equivalent). Unlike e2fsprogs, we can check its version

[PATCH] Trivial fix for typos in comments.

Signed-off-by: Nicholas D Steeves --- fs/btrfs/disk-io.c | 2 +- fs/btrfs/extent-tree.c | 2 +- fs/btrfs/file.c| 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c index 50bed6c..c66c752 100644 ---

[PATCH] Trivial fix for typos in comments.

Trivial fix for typos in comments; I hope this patch isn't a nuisance! Nicholas D Steeves (1): Trivial fix for typos in comments. fs/btrfs/disk-io.c | 2 +- fs/btrfs/extent-tree.c | 2 +- fs/btrfs/file.c| 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) -- 2.1.4 -- To

Re: [PATCH 3/3] Btrfs: don't do unnecessary delalloc flushes when relocating

On Mon, Apr 25, 2016 at 02:01:12AM +0100, fdman...@kernel.org wrote: > From: Filipe Manana > > Before we start the actual relocation process of a block group, we do > calls to flush delalloc of all inodes and then wait for ordered extents > to complete. However we do these

Re: [PATCH 2/3] Btrfs: don't wait for unrelated IO to finish before relocation

On Mon, Apr 25, 2016 at 02:01:11AM +0100, fdman...@kernel.org wrote: > From: Filipe Manana > > Before the relocation process of a block group starts, it sets the block > group to readonly mode, then flushes all delalloc writes and then finally > it waits for all ordered

Re: [PATCH 1/3] Btrfs: fix race in relocation that makes us miss extents

On Mon, Apr 25, 2016 at 02:01:10AM +0100, fdman...@kernel.org wrote: > From: Filipe Manana > > Before it starts the actual process of moving extents, relocation first > sets the block group to read only mode, to prevent tasks from allocating > new extents from it, and then

Re: empty disk reports full

On Mon, May 9, 2016 at 4:56 AM, Alejandro Vargas wrote: > El Martes, 26 de abril de 2016 00:08:49 Chris Murphy escribió: >> On Mon, Apr 25, 2016 at 8:03 AM, Alejandro Vargas wrote: > >> I suggest unmounting and running 'btrfs check' (without repair) and >> see if

Re: btrfs ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair

On Mon, May 9, 2016 at 8:53 AM, Niccolò Belli wrote: > I cannot manage to survive such annoying workflow for long, so I really hope > someone will manage to track the bug down soon. I suggest perseverance :) despite how tedious this is. Btrfs is more aware of its

Re: [PATCH 07/14] Btrfs: introduce ticketed enospc infrastructure

On Fri, Mar 25, 2016 at 01:25:53PM -0400, Josef Bacik wrote: > Our enospc flushing sucks. It is born from a time where we were early > enospc'ing constantly because multiple threads would race in for the same > reservation and randomly starve other ones out. So I came up with this > solution >

Re: btrfs ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair

Hi, Le 09/05/2016 16:53, Niccolò Belli a écrit : > On domenica 8 maggio 2016 20:27:55 CEST, Patrik Lundquist wrote: >> Are you using any power management tweaks? > > Yes, as stated in my very first post I use TLP with > SATA_LINKPWR_ON_BAT=max_performance, but I managed to reproduce the > bug

Re: btrfs ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair

Austin S. Hemmelgarn posted on Mon, 09 May 2016 14:21:57 -0400 as excerpted: > This practice evolved out of the fact that the only bad RAM I've ever > dealt with either completely failed to POST (which can have all kinds of > interesting symptoms if it's just one module, some MB's refuse to boot,

Re: btrfs ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair

On 2016-05-09 12:29, Zygo Blaxell wrote: On Mon, May 09, 2016 at 04:53:13PM +0200, Niccolò Belli wrote: While trying to find a common denominator for my issue I did lots of backups of /dev/mapper/cryptroot and I restored them into /dev/mapper/cryptroot dozens of times (triggering a 150GB+

Re: commands like "du", "df", and "btrfs fs sync" hang

Am Mon, 9 May 2016 13:13:53 -0400 schrieb Nicholas D Steeves : > On May 7, 2016 7:43 AM, "Kai Krakow" wrote: > > > > Am Thu, 5 May 2016 08:35:37 +0200 > > schrieb Kai Krakow : > > > > > Am Tue, 3 May 2016 08:48:14 +0200 > > >

Re: btrfs goes readonly + No space left on 4.3

Stefan Priebe - Profihost AG posted on Mon, 09 May 2016 14:59:25 +0200 as excerpted: > Am 03.05.2016 um 00:05 schrieb Omar Sandoval: >> On Fri, Apr 29, 2016 at 10:48:15PM +0200, Stefan Priebe wrote: >>> just want to drop a note that all those ENOSPC msg are gone with v4.5 >>> and space_cache=v2.

Re: [PATCH] btrfs: fix memory leak during RAID 5/6 device replacement

CC Zhao Lei On Mon, May 09, 2016 at 09:14:28AM -0400, Scott Talbert wrote: > A 'struct bio' is allocated in scrub_missing_raid56_pages(), but it was never > freed anywhere. > > Signed-off-by: Scott Talbert > --- > fs/btrfs/scrub.c | 2 ++ > 1

Re: commands like "du", "df", and "btrfs fs sync" hang

On May 7, 2016 7:43 AM, "Kai Krakow" wrote: > > Am Thu, 5 May 2016 08:35:37 +0200 > schrieb Kai Krakow : > > > Am Tue, 3 May 2016 08:48:14 +0200 > > schrieb Kai Krakow : > > > > > Am Sun, 1 May 2016 20:39:31 -0400 > > > schrieb

Re: [PATCH v2] btrfs-progs: udev: add rules for dm devices

On Mon, May 09, 2016 at 11:44:26AM -0400, Jeff Mahoney wrote: > Systemd's btrfs rule runs btrfs dev ready on each device > as it's discovered. The btrfs command is executed as a builtin > command via an IMPORT{builtin} rule, which means it gets > executed at rule evaluation time, not rule

Re: btrfs ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair

On Mon, May 09, 2016 at 04:53:13PM +0200, Niccolò Belli wrote: > While trying to find a common denominator for my issue I did lots of backups > of /dev/mapper/cryptroot and I restored them into /dev/mapper/cryptroot > dozens of times (triggering a 150GB+ random data write every time), without >

[PATCH v2] btrfs-progs: udev: add rules for dm devices

Systemd's btrfs rule runs btrfs dev ready on each device as it's discovered. The btrfs command is executed as a builtin command via an IMPORT{builtin} rule, which means it gets executed at rule evaluation time, not rule execution time. That means that the device mapper links haven't been setup

Re: btrfs ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair

On domenica 8 maggio 2016 20:27:55 CEST, Patrik Lundquist wrote: Are you using any power management tweaks? Yes, as stated in my very first post I use TLP with SATA_LINKPWR_ON_BAT=max_performance, but I managed to reproduce the bug even without TLP. Also in the past week I've alwyas been on

[PATCH 2/2] Btrfs: fix race between block group relocation and nocow writes

From: Filipe Manana Relocation of a block group waits for all existing tasks flushing dellaloc, starting direct IO writes and any ordered extents before starting the relocation process. However for direct IO writes that end up doing nocow (inode either has the flag nodatacow

[PATCH 1/2] Btrfs: fix race between fsync and direct IO writes for prealloc extents

From: Filipe Manana When we do a direct IO write against a preallocated extent (fallocate) that does not go beyond the i_size of the inode, we do the write operation without holding the inode's i_mutex (an optimization that landed in commit 38851cc19adb ("Btrfs: implement

[PATCH] btrfs: fix memory leak during RAID 5/6 device replacement

A 'struct bio' is allocated in scrub_missing_raid56_pages(), but it was never freed anywhere. Signed-off-by: Scott Talbert --- fs/btrfs/scrub.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c index 82bedf9..607cc6e 100644 ---

Re: btrfs goes readonly + No space left on 4.3

Am 03.05.2016 um 00:05 schrieb Omar Sandoval: > On Fri, Apr 29, 2016 at 10:48:15PM +0200, Stefan Priebe wrote: >> just want to drop a note that all those ENOSPC msg are gone with v4.5 and >> space_cache=v2. Any plans to make space_cache=v2 default? >> >> Greets, >> Stefan > > Yup, we want to

[PATCH] btrfs: GFP_NOFS does not GFP_HIGHMEM

Masking HIGHMEM out of NOFS does not make sense. Signed-off-by: David Sterba --- fs/btrfs/delayed-inode.c | 2 +- fs/btrfs/disk-io.c | 2 +- fs/btrfs/extent_io.c | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/fs/btrfs/delayed-inode.c

Re: btrfs ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair

On 2016-05-07 12:11, Niccolò Belli wrote: Il 2016-05-07 17:58 Clemens Eisserer ha scritto: Hi Niccolo, btrfs + dmcrypt + compress=lzo + autodefrag = corruption at first boot Just to be curious - couldn't it be a hardware issue? I use almost the same setup (compress-force=lzo instead of

Re: empty disk reports full

El Martes, 26 de abril de 2016 00:08:49 Chris Murphy escribió: > On Mon, Apr 25, 2016 at 8:03 AM, Alejandro Vargas wrote: > I suggest unmounting and running 'btrfs check' (without repair) and > see if that gives any new information. I tried btrfs check but... see the result: #

Re: [PATCH] btrfs: fix int32 overflow in shrink_delalloc().

On Sun, May 08, 2016 at 03:08:00PM +0200, Adam Borowski wrote: > UBSAN: Undefined behaviour in fs/btrfs/extent-tree.c:4623:21 > signed integer overflow: > 10808 * 262144 cannot be represented in type 'int [8]' > > If 8192<=items<16384, we request a writeback of an insane number of pages > which

[PATCH] btrfs: switch to common message helpers in open_ctree, adjust messages

Currently we lack the identification of the filesystem in most if not all mount messages, done via printk/pr_* functions. We can use the btrfs_* helpers in open_ctree, as the fs_info <-> sb link is established at the beginning of the function. The messages have been updated at the same time to be

[PATCH 3/3] btrfs-progs: prop: remove conditions which never be satisfied

parse_args() always set at least one parameter, 'object', for {get,list} subcommands. In addition, it always set all three parameters, 'object', 'name', and 'value' for set subcommand. So the following conditions can be removed. Signed-off-by: Satoru Takeuchi ---

[PATCH 2/3] btrfs-progs: prop: simplify parse_args()

Since parameter is mandatory for all subcommands, 'object' is always set by parse_args()'s callers. In addition, on setting '*name' and '*value', if 'optind < argc' is satisfied here, they are always set by parse_args()'s callers. Signed-off-by: Satoru Takeuchi

[PATCH 1/3] btrfs-progs: prop: convert error messages to use error()

props.c uses 'fprintf(stderr, "ERROR: ...")' as its error messages, however we have generic error() function. Signed-off-by: Satoru Takeuchi --- props.c | 21 + 1 file changed, 9 insertions(+), 12 deletions(-) diff --git a/props.c b/props.c