Thanks Anna,
the whole series looks good to me,
Reviewed-by: Christoph Hellwig
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello,
I have a a single version of this drive formatted with btrfs. Its my
only btrfs drive on this machine.
I'm getting similar errors. Is there any info I can provide to help
troubleshoot this?
Is a full dmesg still wanted?
here's what I'm running-
$ uname -a
Linux machine 4.2.0-16-lowlatenc
This looks like a deadlock in FIEMAP:
# cat /proc/version
Linux version 4.1.8-zb64+ (root@buildhost) (gcc version 4.9.2 (Debian
4.9.2-10) ) #1 SMP PREEMPT Tue Sep 22 00:54:04 EDT 2015
# cat /proc/6943/stack
[] lock_extent_bits+0x1ad/0x200
[] extent_fiemap+
From: Zach Brown
Add sys_copy_file_range to the x86 syscall tables.
Signed-off-by: Zach Brown
[Anna Schumaker: Update syscall number in syscall_32.tbl]
Signed-off-by: Anna Schumaker
---
arch/x86/entry/syscalls/syscall_32.tbl | 1 +
arch/x86/entry/syscalls/syscall_64.tbl | 1 +
2 files changed
From: Zach Brown
Add a copy_file_range() system call for offloading copies between
regular files.
This gives an interface to underlying layers of the storage stack which
can copy without reading and writing all the data. There are a few
candidates that should support copy offloading in the near
From: Zach Brown
This rearranges the existing COPY_RANGE ioctl implementation so that the
.copy_file_range file operation can call the core loop that copies file
data extent items.
The extent copying loop is lifted up into its own function. It retains
the core btrfs error checks that should be
Copy system calls came up during Plumbers a while ago, mostly because several
filesystems (including NFS and XFS) are currently working on copy acceleration
implementations. We haven't heard from Zach Brown in a while, so I volunteered
to push his patches upstream so individual filesystems don't n
This allows us to have an in-kernel copy mechanism that avoids frequent
switches between kernel and user space. This is especially useful so
NFSD can support server-side copies. Let's first check if the filesystem
supports any kind of copy acceleration, but fall back on copying through the
pageca
copy_file_range() is a new system call for copying ranges of data
completely in the kernel. This gives filesystems an opportunity to
implement some kind of "copy acceleration", such as reflinks or
server-side-copy (in the case of NFS).
Signed-off-by: Anna Schumaker
Reviewed-by: Darrick J. Wong
On Fri, Oct 23, 2015 at 4:41 PM, Malte Schröder wrote:
> Hi,
> kernel 4.2 crashes more or less reliably when running btrfs balance.
> The filesystem in question is running in RAID1 mode. This happens quite
> reliably.
> Btrfs filesystem check doesn't show any problems.
>
> Dmesg output is attached
Hi,
kernel 4.2 crashes more or less reliably when running btrfs balance.
The filesystem in question is running in RAID1 mode. This happens quite
reliably.
Btrfs filesystem check doesn't show any problems.
Dmesg output is attached.
I'll happily provide more information if needed.
Regards
Malte[
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/21/15 4:45 AM, Anand Jain wrote:
> mkfs from latest btrfs-progs will enable latest default features,
> and if the kernel is down-rev and does not support a latest
> default feature then mount fails, as expected.
>
> This patch disables default
On Fri, Oct 23, 2015 at 4:11 PM, Jeff Mahoney wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/23/15 4:03 AM, Zhao Lei wrote:
>> Since we set source bg to readonly in scrub/replace, we don't need
>> to consider confliction of no-cow write in scrub/replace operaion.
>
> What happe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/23/15 4:03 AM, Zhao Lei wrote:
> Since we set source bg to readonly in scrub/replace, we don't need
> to consider confliction of no-cow write in scrub/replace operaion.
What happens if there's a read failure? IIRC the initial purpose of
this c
On 23.10.2015 01:47, Qu Wenruo wrote:
> 在 2015年10月23日 04:38, Johannes Henninger 写道:
>> I'm having a weird problem with snapshots and exclusive quotas. After
>> creating a snapshot of a subvolume and setting an exclusive quota of
>> 50MB for the snapshot, everything seems to work fine. I can write
>
Le 2015-10-23 12:59, Stéphane Lesimple a écrit :
Le 2015-10-23 12:11, Filipe Manana a écrit :
On Fri, Oct 23, 2015 at 12:03 AM, Filipe Manana
wrote:
On Thu, Oct 22, 2015 at 11:38 PM, Stéphane Lesimple
wrote:
[ ... thread cleanup ... ]
Don't hesitate to ask if you need me to debug or even ft
Hi Linus,
I have two more small fixes this week in my for-linus-4.3 branch:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git
for-linus-4.3
Qu's fix avoids unneeded COW during fallocate, and Christian
found a memory leak in the error handling of an earlier fix.
Qu Wenruo (1)
Zygo, you are right
Thread closed, thanks
2015-10-23 3:14 GMT+03:00 Zygo Blaxell :
> On Tue, Oct 20, 2015 at 04:29:46PM +0300, Timofey Titovets wrote:
>> For performance reason, leave data at the start of disk, is preferable
>> while deduping
>> It's might sense for the reasons:
>> 1. Spinning rus
On Thu, Oct 22, 2015 at 11:58:05AM +0800, Anand Jain wrote:
S-O-B line added and applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Le 2015-10-23 12:11, Filipe Manana a écrit :
On Fri, Oct 23, 2015 at 12:03 AM, Filipe Manana
wrote:
On Thu, Oct 22, 2015 at 11:38 PM, Stéphane Lesimple
wrote:
[ ... thread cleanup ... ]
Don't hesitate to ask if you need me to debug or even ftrace
something.
Thanks Stéphane. I haven't see
On Fri, Oct 23, 2015 at 12:03 AM, Filipe Manana wrote:
> On Thu, Oct 22, 2015 at 11:38 PM, Stéphane Lesimple
> wrote:
> [ ... thread cleanup ... ]
>
> Don't hesitate to ask if you need me to debug or even ftrace something.
Thanks Stéphane. I haven't seen that crash yet
On Fri, Oct 23, 2015 at 3:04 AM, Qu Wenruo wrote:
> Ancient qgroup code call memcpy() on a extent buffer and use it for leaf
> iteration.
>
> As extent buffer contains lock, pointers to pages, it's never sane to do
> such copy.
>
> The following bug may be caused by this insane operation:
> [92098
On Thu, Oct 22, 2015 at 11:53:39AM +0800, Anand Jain wrote:
> Noticed that at print_one_uuid() some of the members of btrfs_fs_devices
> contained some junk values. It took a while to dig this further, and found
> that we make a local copy of the btrfs_fs_devices list at
> search_umounted_fs_uuids(
Since we set source bg to readonly in scrub/replace, we don't need
to consider confliction of no-cow write in scrub/replace operaion.
This patch removes special code for no-cow mode in scrub/replace,
reduced 670 lines.
Tested by continuous xfstests in 5 days, include generic and btrfs
groups with
24 matches
Mail list logo
