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 -l in-progress/mysterious-io-error
>> -rw
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.
Wh
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 (Sor
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).
>
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 wi
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
--- a/fs/btrfs/disk-io.c
+++ b/fs
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 unsu
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 flush calls just to mak
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 extents to complete. This
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 flushes delalloc and wa
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 that gives any new information.
>
On Fri, Mar 25, 2016 at 01:25:58PM -0400, Josef Bacik wrote:
> We were doing trace_btrfs_release_reserved_extent() in pin_down_extent which
> isn't quite right because we will go through and free that extent later when
> we
> unpin, so it messes up apps that are accounting for the reservation spac
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 state than other file systems, s
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
> t
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 even
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,
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+ random
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
> > > schrieb Kai Krakow :
> > >
> [...]
> [...]
> > > [...]
>
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. A
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 file changed, 2 insertions(+)
>
> diff --git a/fs/
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 Nicholas D Steeves :
> > >
> > > > On 1 May 2016 at 03:00, Kai Krakow
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 executio
On Mon, May 09, 2016 at 12:46:46PM +0800, Qu Wenruo wrote:
> The new convert framework copies code from current dumpe2fs, which uses
> BIGALLOC feature introduced in e2fsprogs v1.42.
>
> While there are a lot of enterprise distributions which are still using
> v1.41 e2fsprogs, this will cause comp
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
> any
On Mon, May 09, 2016 at 04:20:01PM +0900, Satoru Takeuchi wrote:
> props.c uses 'fprintf(stderr, "ERROR: ...")' as its error messages,
> however we have generic error() function.
>
> Signed-off-by: Satoru Takeuchi
All applied, thanks. I did some minor tweaks to the messages in 1/3 to
be consiste
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 -l in-progress/mysterious-io-error
> -rw-rw-r-- 1 nikratio nikratio 10485760 May 8 14:
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 ye
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 A
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 set or the write is
a
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 unlocked dio write")). T
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
--- a/fs/btrfs/scrub.c
+++ b/fs/
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 make
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 b/fs/btrfs/delayed-inode.c
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 compr
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:
# btrfs check /dev/
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 is
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
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
---
cmds-property.c | 12 --
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
---
cmds-property.c | 13 +--
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
index 5b74932..5b4e26e 100644
---
40 matches
Mail list logo