On 2014/03/27 04:51 AM, Gui Hecheng wrote:
[snip]
We add t/p/e support by replacing lib/cmdline.c:memparse
with btrfs_memparse. The btrfs_memparse copies memparse's code
and add unit t/p/e parsing.
Is there a conflict preventing adding this to memparse directly?
--
__
Brendan Hide
The ioctl for the whole range is not interruptible, which can be
annoying when the discard is not wanted but user forgets to use the -K
option.
Signed-off-by: David Sterba dste...@suse.cz
---
utils.c | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git
On Thu, Mar 27, 2014 at 09:35:41AM +0200, Brendan Hide wrote:
On 2014/03/27 04:51 AM, Gui Hecheng wrote:
[snip]
We add t/p/e support by replacing lib/cmdline.c:memparse
with btrfs_memparse. The btrfs_memparse copies memparse's code
and add unit t/p/e parsing.
Is there a conflict preventing
Hi Tsutomu Itoh,
On Thu, Mar 21, 2013 at 6:32 AM, Tsutomu Itoh t-i...@jp.fujitsu.com wrote:
We should free leaf and root before returning from the error
handling code.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/disk-io.c | 12 +---
1 file changed, 9
On Thu, Mar 06, 2014 at 01:54:56PM +0800, Miao Xie wrote:
@@ -349,10 +349,13 @@ int btrfs_dec_test_first_ordered_pending(struct inode
*inode,
if (!uptodate)
set_bit(BTRFS_ORDERED_IOERR, entry-flags);
- if (entry-bytes_left == 0)
+ if (entry-bytes_left == 0) {
The real check whether to show deleted or live subvolumes was skipped if
just '-d' was specified without other filters. The 'deleted' filter was
not accounted.
Signed-off-by: David Sterba dste...@suse.cz
---
btrfs-list.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git
This was done to allow NO_COW to continue to be NO_COW after relocation but it
is not right. When relocating we will convert blocks to FULL_BACKREF that we
relocate. We can leave some of these full backref blocks behind if they are not
cow'ed out during the relocation, like if we fail the
This is a continuation of the previous changes titled:
Btrfs: fix incremental send's decision to delay a dir move/rename
Btrfs: part 2, fix incremental send's decision to delay a dir move/rename
There's a few more cases where a directory rename/move must be delayed which was
previously
There were recently fixed issues where an incremental send would enter
an infinite loop when building a path string, which made it krealloc the
path buffer over and over. This eventually lead to a kernel crash because
we track the buffer's size in a 15 bits unsigned integer and eventually we
ended
From: Filipe Manana fdman...@gmail.com
Regression test for a btrfs incremental send issue where the kernel failed
to build paths strings. This resulted either in sending a wrong path string
to the send stream or entering an infinite loop when building it.
This happened in the following scenarios:
Is btrfs supposed to handle disk failures in RAID-1 mode?
It doesn't seem to be the case for me, with 3.14.0-rc8.
Right now, the system doesn't see the faulty drive anymore (i.e. hdparm -i
/dev/sdd is unable to give any info).
Accesses to most files on btrfs filesystem just freeze (waiting for
We could have possibly added an extent_op to the locked_ref while we dropped
locked_ref-lock, so check for this case as well and loop around. Otherwise we
could lose flag updates which would lead to extent tree corruption. Thanks,
cc: sta...@vger.kernel.org
Signed-off-by: Josef Bacik
We were having corruption issues that were tied back to problems with the extent
tree. In order to track them down I built this tool to try and find the
culprit, which was pretty successful. If you compile with this tool on it will
live verify every ref update that the fs makes and make sure it
On Thu, 2014-03-27 at 16:27 +0100, David Sterba wrote:
On Thu, Mar 27, 2014 at 09:35:41AM +0200, Brendan Hide wrote:
On 2014/03/27 04:51 AM, Gui Hecheng wrote:
[snip]
We add t/p/e support by replacing lib/cmdline.c:memparse
with btrfs_memparse. The btrfs_memparse copies memparse's code
14 matches
Mail list logo
