On Sat, Feb 6, 2016 at 2:35 PM, Tom Arild Naess wrote:
> Hello,
>
> I have quite recently converted my file server to btrfs, and I am in the
> progress of setting up a new backup server with btrfs to be able to utilize
> btrfs send/receive.
>
> FIle server:
>>
>> uname -a
>
>
On Thu, Feb 4, 2016 at 8:11 PM, Anand Jain wrote:
>
>
> If you look critically we have been using UI/CLI as API,
> IMO these two class of interfaces be distinct clearly.
>
> Btrfs needs library functions/APIs which is callable in
> popular scripting language like
Hello,
I have quite recently converted my file server to btrfs, and I am in the
progress of setting up a new backup server with btrfs to be able to
utilize btrfs send/receive.
FIle server:
uname -a
Linux main 3.19.0-49-generic #55~14.04.1-Ubuntu SMP Fri Jan 22 11:24:31
UTC 2016 x86_64
On 07. feb. 2016 00:32, Chris Murphy wrote:
It's probably unrelated the problem, but I would given the many bug
fixes (including in send/receive) since kernel 3.19, and progs 4.1,
that I'd get both systems using the same kernel and progs version. I
suspect most of upstream's testing before
kernel 4.1.15
balancing a fs led to this oops.
after a reboot, the balance resumed without problem.
presumably there wasn't enough real memory available
David
[ cut here ]
WARNING: CPU: 1 PID: 16560 at fs/btrfs/super.c:260
__btrfs_abort_transaction+0x4b/0x120
CURRENT_TIME macro is not appropriate for filesystems as it
doesn't use the right granularity for filesystem timestamps.
Use current_fs_time() instead.
Signed-off-by: Deepa Dinamani
Cc: Chris Mason
Cc: Josef Bacik
Cc: David Sterba
Mackenzie Meyer posted on Fri, 05 Feb 2016 14:36:33 -0500 as excerpted:
> Hello,
>
> I've tried checking around on google but can't find information
> regarding the RAM requirements of BTRFS and most of the topics on
> stability seem quite old.
>
> So first would be memory requirements, my goal