Actually it seems strange that a send operation could corrupt the
source subvolume or fs. Why would the send modify the source subvolume
in any significant way? The only way I can find to reconcile your
observations with mine is that maybe the snapshots get corrupted not
by the send operation by
On 10/13/2014 02:40 PM, john terragon wrote:
Actually it seems strange that a send operation could corrupt the
source subvolume or fs. Why would the send modify the source subvolume
in any significant way? The only way I can find to reconcile your
observations with mine is that maybe the
On Sun, Oct 12, 2014 at 7:11 AM, David Arendt ad...@prnet.org wrote:
This weekend I finally had time to try btrfs send again on the newly
created fs. Now I am running into another problem:
btrfs send returns: ERROR: send ioctl failed with -12: Cannot allocate
memory
In dmesg I see only the
This weekend I finally had time to try btrfs send again on the newly
created fs. Now I am running into another problem:
btrfs send returns: ERROR: send ioctl failed with -12: Cannot allocate
memory
In dmesg I see only the following output:
parent transid verify failed on 21325004800 wanted 2620
Hi.
I just wanted to confirm David's story so to speak :)
-kernel 3.17-rc7 (didn't bother to compile 3.17 as there weren't any
btrfs fixes, I think)
-btrfs-progs 3.16.2 (also compiled from source, so no
distribution-specific patches)
-fresh fs
-I get the same two errors David got (first I got
Just to let you know, I just tried an ls -l on 2 machines running kernel
3.17 and btrfs-progs 3.16.2.
Here is my ls -l output:
Machine 1:
ls: cannot access root.20141009.000503.backup: Cannot allocate memory
total 0
d? ? ? ? ?? root.20141009.000503.backup
Some more info I thought off. For me, the corruption problem seems not
to be send related but snapshot creation related. On machine 2 send was
never used. However both filesystems are stored on SSDs (of different
brand). Another filesystem stored on a normal HDD didn't experience the
problem.
On Tue, Oct 7, 2014 at 1:25 AM, David Arendt ad...@prnet.org wrote:
I did a revert of this commit. After creating a snapshot, the
filesystem was no longer usable, even with kernel 3.16.3 (crashes 10
seconds after mount without error message) . Maybe there was some
previous damage that just
On 10/07/2014 03:19 PM, Chris Mason wrote:
On Tue, Oct 7, 2014 at 1:25 AM, David Arendt ad...@prnet.org wrote:
I did a revert of this commit. After creating a snapshot, the
filesystem was no longer usable, even with kernel 3.16.3 (crashes 10
seconds after mount without error message) . Maybe
On Tue, Oct 7, 2014 at 4:45 PM, David Arendt ad...@prnet.org wrote:
On 10/07/2014 03:19 PM, Chris Mason wrote:
On Tue, Oct 7, 2014 at 1:25 AM, David Arendt ad...@prnet.org
wrote:
I did a revert of this commit. After creating a snapshot, the
filesystem was no longer usable, even with
On Mon, Oct 6, 2014 at 2:50 PM, David Arendt ad...@prnet.org wrote:
Hi,
After upgrading to kernel 3.17 btrfs send has stopped working.
ERROR: send ioctl failed with -5: Input/output error
The following message is printed by kernel:
[75322.782197] BTRFS error (device sda2): did not find
I have upgraded from kernel 3.16.3.
emerge-fetch.log is a simple append-only log file. Other files having
the problems after deleting them one by one have been emerge.log,
mysql.log, freshclam.log and main.cvd from clamav. At this one, I
stopped deleting.
On 10/06/2014 09:06 PM, Chris Mason
I just tried downgrading to 3.16.3 again. In 3.16.3 btrfs send is
working without any problem. Afterwards I upgraded again to 3.17 and the
problem reappeared. So the problem seems to be kernel version related.
On 10/06/2014 09:06 PM, Chris Mason wrote:
On Mon, Oct 6, 2014 at 2:50 PM, David
On Mon, Oct 6, 2014 at 4:51 PM, David Arendt ad...@prnet.org wrote:
I just tried downgrading to 3.16.3 again. In 3.16.3 btrfs send is
working without any problem. Afterwards I upgraded again to 3.17 and
the
problem reappeared. So the problem seems to be kernel version related.
[ backref
14 matches
Mail list logo
