Just in case if need to fix it properly, this patch helps.
Its a bit of overkill though, on the basis of being theoretically
correct. As discussed, this or Chris suggested to use simpler
BTRFS_SUBVOL_NAME_MAX will fix equally from practical perspective.
This patch is ontop the patch
btrfs:
Add device ioctl uses BTRFS_PATH_NAME_MAX however delete
uses BTRFS_SUBVOL_NAME_MAX to hold device path. This patch
makes them consistent.
Depends on
btrfs: make add and device ioctl args path max consistent
Signed-off-by: Anand Jain
---
cmds-device.c | 2 +-
ioctl.h | 19 +
Add device ioctl uses BTRFS_PATH_NAME_MAX however delete
uses BTRFS_SUBVOL_NAME_MAX for device path. This patch makes
them consistent.
Signed-off-by: Anand Jain
---
fs/btrfs/ioctl.c | 2 +-
include/uapi/linux/btrfs.h | 19 ++-
2 files changed, 19 insertions(+), 2 dele
Greetings,
I'm getting reproducible Oopses when attempting "btrfs send" on my
root vol, quickly ending in a hard lockup of the machine. Both
incremental send and non-incremental send crash, the former much
earlier. The volume is in a LUKS container.
The initial fault is always during LZO decompre
On Thu, Feb 18, 2016 at 03:14:04PM +0800, Anand Jain wrote:
>
>
> Thanks Dan.
> Chris pointed out as well. We are working on it..
In for next since yesterday.
> Just one concern when device is added the max device length is
> BTRFS_PATH_NAME_MAX. However below fix is proper from the vol_a
On Wed, Feb 17, 2016 at 07:04:41PM +0800, kbuild test robot wrote:
> fs/btrfs/volumes.c:1886:2-7: WARNING: NULL check before freeing functions
> like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb is not
> needed. Maybe consider reorganizing relevant code to avoid passing NULL
>
On Thu, Feb 18, 2016 at 09:37:41AM +0800, Zhao Lei wrote:
> CC: David Sterba
> I'll fix this indent problem in following branch:
> https://github.com/zhaoleidd/btrfs.git integration-4.5
>
> Could you pick them again?
Done, fixed manually and updated in for-next.
--
To unsubscribe from this list:
On Thu, Feb 18, 2016 at 02:59:26PM +0800, Anand Jain wrote:
> #define BTRFS_PATH_NAME_MAX 4087
> #define BTRFS_SUBVOL_NAME_MAX 4039
>
> I am fine with using BTRFS_SUBVOL_NAME_MAX for now. But theoretical
> anomaly is that add-device code path will use BTRFS_PATH_NAME_MAX and
> delete device
Filipe Manana posted on Wed, 17 Feb 2016 14:01:15 + as excerpted:
> Just upgrade to a 4.3 or 4.4 kernel, or build a kernel with the patch
> below.
> The fix for this landed in 4.3:
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?
id=d6589101b67a55107652050dfbf41440
On 02/14/2016 11:42 PM, Roman Mamedov wrote:
> FWIW I had a persistently repeating deadlock on 4.1 and 4.3, but
> after upgrade to 4.4 it no longer happens.
Apparently also with 4.4 there is some sort of blocking happening ...
just at 38580:
cut
[Wed Feb 17 16:43:48 2016] INFO: task
The control device is accessible when no filesystem is mounted and we
may want to query features supported by the module. This is already
possible using the sysfs files, this ioctl is for parity and
convenience.
Signed-off-by: David Sterba
---
fs/btrfs/ctree.h | 1 +
fs/btrfs/ioctl.c | 3 +--
fs
Signed-off-by: David Sterba
---
fs/btrfs/ctree.h | 2 +-
fs/btrfs/ioctl.c | 4 ++--
fs/btrfs/super.c | 3 +--
3 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 47bc50fd4f55..82ce847318ae 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@
On Thu, Feb 18, 2016 at 1:30 AM, Dave Chinner wrote:
> On Mon, Feb 15, 2016 at 10:54:23AM +, fdman...@kernel.org wrote:
>> From: Filipe Manana
>>
>> Test that if we move one file between directories, fsync the parent
>> directory of the old directory, power fail and remount the filesystem,
>>
On Sat, Feb 13, 2016 at 10:01:40AM +0800, Anand Jain wrote:
> Optimize check for stale device to only be checked when there is device
> added or changed. If there is no update to the device, there is no need
> to call btrfs_free_stale_device().
>
> Signed-off-by: Anand Jain
http://thread.gmane.o
On Thu, Feb 18, 2016 at 01:38:41PM +, Filipe Manana wrote:
> On Thu, Feb 18, 2016 at 1:30 AM, Dave Chinner wrote:
> > On Mon, Feb 15, 2016 at 10:54:23AM +, fdman...@kernel.org wrote:
> >> From: Filipe Manana
> >>
> >> Test that if we move one file between directories, fsync the parent
> >
On Thu, Feb 18, 2016 at 4:43 PM, Darrick J. Wong
wrote:
> On Thu, Feb 18, 2016 at 01:38:41PM +, Filipe Manana wrote:
>> On Thu, Feb 18, 2016 at 1:30 AM, Dave Chinner wrote:
>> > On Mon, Feb 15, 2016 at 10:54:23AM +, fdman...@kernel.org wrote:
>> >> From: Filipe Manana
>> >>
>> >> Test th
On Tue, Oct 06, 2015 at 05:33:10PM +0800, Anand Jain wrote:
> From: Anand Jain
>
> This patch introduces new option for the command
>
> btrfs device delete [..]
>
> In a user reported issue on a 3-disk-RAID1, one disk failed with its
> SB unreadable. Now with this patch user will have a ch
On Thu, Feb 18, 2016 at 01:35:24PM +0100, Christian Rohmann wrote:
>
>
> On 02/14/2016 11:42 PM, Roman Mamedov wrote:
> > FWIW I had a persistently repeating deadlock on 4.1 and 4.3, but
> > after upgrade to 4.4 it no longer happens.
>
>
> Apparently also with 4.4 there is some sort of blocking
On Thu, Feb 18, 2016 at 9:29 AM, Jan Alexander Steffens
wrote:
> Greetings,
>
> I'm getting reproducible Oopses when attempting "btrfs send" on my
> root vol, quickly ending in a hard lockup of the machine. Both
> incremental send and non-incremental send crash, the former much
> earlier. The volu
From: Filipe Manana
While running a test with a mix of buffered IO and direct IO against
the same files I hit a deadlock reported by the following trace:
[11642.140352] INFO: task kworker/u32:3:15282 blocked for more than 120 seconds.
[11642.142452] Not tainted 4.4.0-rc6-btrfs-next-21+ #1
On Tue, Feb 16, 2016 at 5:44 AM, Nazar Mokrynskyi wrote:
> I have 2 SSD with BTRFS filesystem (RAID) on them and several subvolumes.
> Each 15 minutes I'm creating read-only snapshot of subvolumes /root, /home
> and /web inside /backup.
> After this I'm searching for last common subvolume on /back
On Thu, Feb 18, 2016 at 05:42:50PM +, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> While running a test with a mix of buffered IO and direct IO against
> the same files I hit a deadlock reported by the following trace:
>
> [11642.140352] INFO: task kworker/u32:3:15282 blocked for mor
On Thu, Feb 18, 2016 at 7:53 PM, Liu Bo wrote:
> On Thu, Feb 18, 2016 at 05:42:50PM +, fdman...@kernel.org wrote:
>> From: Filipe Manana
>>
>> While running a test with a mix of buffered IO and direct IO against
>> the same files I hit a deadlock reported by the following trace:
>>
>> [11642.
From: Filipe Manana
Test that if we fsync a directory that had a snapshot entry in it that
was deleted and crash, the next time we mount the filesystem, the log
replay procedure will not fail and the snapshot is not present anymore.
This issue is fixed by the following patch for the linux kernel
From: Filipe Manana
Test that if we move one file between directories, fsync the parent
directory of the old directory, power fail and remount the filesystem,
the file is not lost and it's located at the destination directory.
This is motivated by a bug found in btrfs, which is fixed by the patc
From: Filipe Manana
Test that if we have a file F1 with two links, one in a directory A and
the other in directory B, if we remove the link in directory B, move some
other file F2 from directory B into directory C, fsync inode F1, power
fail and remount the filesystem, file F2 exists and is locat
On Thu, Feb 18, 2016 at 3:03 AM, Qu Wenruo wrote:
>
>
> Dan Blazejewski wrote on 2016/02/17 18:04 -0500:
>>
>> Hello,
>>
>> I upgraded my kernel to 4.4.2, and btrfs-progs to 4.4. I also added
>> another 4TB disk and kicked off a full balance (currently 7x4TB
>> RAID6). I'm interested to see what a
Qu, thanks for your input. I cancelled the existing balance, and
kicked off a balance set to dconvert=single. Should be busy for the
next few days, but I already see the multiple RAID 6 stripes
disappearing, and the chunk distribution across all drives is starting
to normalize. I'll let you know if
Henk Slager wrote on 2016/02/19 00:27 +0100:
On Thu, Feb 18, 2016 at 3:03 AM, Qu Wenruo wrote:
Dan Blazejewski wrote on 2016/02/17 18:04 -0500:
Hello,
I upgraded my kernel to 4.4.2, and btrfs-progs to 4.4. I also added
another 4TB disk and kicked off a full balance (currently 7x4TB
RAID6
The rule to create symlink in Makefile caused parallel issue:
$ make -j 40 DESTDIR=/image install BUILD_VERBOSE=1
...
1 [LN] libbtrfs.so.0
2 [LN] libbtrfs.so
3 ln -s -f libbtrfs.so.0.1 libbtrfs.so.0
4 ln -s -f libbtrfs.so.0.1 libbtrfs.so.0
5 ln -s -f libbtrfs.so.0.1 libbtr
On 02/18/2016 11:13 PM, David Sterba wrote:
On Sat, Feb 13, 2016 at 10:01:40AM +0800, Anand Jain wrote:
Optimize check for stale device to only be checked when there is device
added or changed. If there is no update to the device, there is no need
to call btrfs_free_stale_device().
Signed-off-
31 matches
Mail list logo