BTRFS: Transaction aborted (error -28)

2016-07-29 Thread Mordechay Kaganer
B.H. Hello! While saving a backup (using rsync) the FS went read only and i've got BTRFS: Transaction aborted (error -28) error. While writing a new backup i was also doing btrfs send of another subvolume on the same FS from this server out to another server. After reboot, the device mounts OK.

Re: BTRFS: Transaction aborted (error -28)

2016-07-31 Thread Mordechay Kaganer
B.H. Thanks for the detailed answer! On Fri, Jul 29, 2016 at 8:23 PM, Duncan <1i5t5.dun...@cox.net> wrote: > ... > Of course the fact that the transaction aborted /does/ indicate some sort > of problem, which may in fact have left the filesystem in an unknown > state. However, I'd recommend a co

Re: BTRFS: Transaction aborted (error -28)

2016-08-04 Thread Mordechay Kaganer
B.H. > On Fri, Jul 29, 2016 at 8:23 PM, Duncan <1i5t5.dun...@cox.net> wrote: >> So I'd recommend upgrading to the latest kernel 4.4 if you want to stay >> with the stable series, or 4.6 or 4.7 if you want current, and then (less >> important) upgrading the btrfs userspace as well. It's possible t

BTRFS: Transaction aborted (ENOSPC)

2016-08-05 Thread Mordechay Kaganer
B.H. Hello. I have a setup with 4 RAID10 arrays, 4 drives each (using md). Device usage is as follows: # btrfs device usage /storage/bkp1 /dev/md1, ID: 1 Device size:10.92TiB Device slack: 0.00B Data,single:10.19TiB Metadata,RAID1:199.00GiB

Transaction aborted (error -17) after crash

2015-11-16 Thread Mordechay Kaganer
B.H. Hello. I have btrfs volume used for backups. The configuration is as follows: # uname -a Linux yemot-4u 4.2.5-040205-generic #201510270124 SMP Tue Oct 27 01:25:49 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux # btrfs --version btrfs-progs v4.2.3 The volume is on top of 2 MD RAID10 arrays, 12TB

Re: Transaction aborted (error -17) after crash

2015-11-17 Thread Mordechay Kaganer
B.H. On Wed, Nov 18, 2015 at 5:02 AM, Qu Wenruo wrote: > > > 在 2015年11月17日 13:12, Mordechay Kaganer 写道: >> >> B.H. >> >> >> [ 836.026606] BTRFS warning (device md1): block group 12969790406656 >> has wrong amount of free space >> [ 836.0266

Re: Transaction aborted (error -17) after crash

2015-11-18 Thread Mordechay Kaganer
B.H. On Wed, Nov 18, 2015 at 7:31 AM, Qu Wenruo wrote: > > Hard to say yet. > > Is that the only error? > > And did you tried btrfsck --init-extent-tree alone? > Although IIRC --init-extent-tree implies --repair, but it seems that extent > tree is not correctly rebuilt at least. btrfs check --in

Fwd: btrfs replace seems to corrupt the file system

2015-06-27 Thread Mordechay Kaganer
B.H. Hello. I'm running our backup archive on btrfs. We have MD-based RAID5 array with 4 6TB disks then LVM on top of it, and btrfs volume on the LV (we don't use btrfs's own RAID features because we want RAID5 and as far as i understand the support is only partial). I wanted to move the archive

Re: btrfs replace seems to corrupt the file system

2015-06-28 Thread Mordechay Kaganer
On Sun, Jun 28, 2015 at 2:17 AM, Mordechay Kaganer wrote: > B.H. > > Hello. I'm running our backup archive on btrfs. We have MD-based RAID5 > array with 4 6TB disks then LVM on top of it, and btrfs volume on the > LV (we don't use btrfs's own RAID features because w

Re: btrfs replace seems to corrupt the file system

2015-06-28 Thread Mordechay Kaganer
B.H. Thanks for the reply. On Sun, Jun 28, 2015 at 7:45 PM, Chris Murphy wrote: > > Option A: Maybe someone has advice on how to get the demoted device to > be valid again as if the replace command hadn't been used. Because > then you could try the replace again with newer kernel and progs, and

Re: btrfs replace seems to corrupt the file system

2015-06-28 Thread Mordechay Kaganer
B.H. On Sun, Jun 28, 2015 at 9:50 PM, Noah Massey wrote: > On Sun, Jun 28, 2015 at 2:02 PM, Mordechay Kaganer wrote: >> To recover the old device, that's what i'm trying to do. Asked on IRC >> also, no reply. As stated above, the device passes btrfs check without &

Re: btrfs replace seems to corrupt the file system

2015-06-28 Thread Mordechay Kaganer
B.H. On Sun, Jun 28, 2015 at 10:32 PM, Chris Murphy wrote: > On Sun, Jun 28, 2015 at 1:20 PM, Mordechay Kaganer wrote: > > >> Then (if it's OK, hopefully) we'll see how to redo the replace. Maybe, >> unmount and do a simple "dd" will be the best option?

Re: btrfs replace seems to corrupt the file system

2015-06-29 Thread Mordechay Kaganer
debugging the issue, please contact me today, before we have wiped it out. On Mon, Jun 29, 2015 at 11:08 AM, Duncan <1i5t5.dun...@cox.net> wrote: > Mordechay Kaganer posted on Mon, 29 Jun 2015 08:02:01 +0300 as excerpted: >> 1. btrfs replace - as far as i understand, it's prima

running duperemove but no free space gain

2015-07-06 Thread Mordechay Kaganer
B.H. Hello. I have a btrfs volume which is used as a backup using rsync from the main servers. It contains many duplicate files across different subvolumes and i have some read only snapshots of each subvolume, which are created every time after the backup completes. I'm was trying to gain some

Re: running duperemove but no free space gain

2015-07-06 Thread Mordechay Kaganer
B.H. On Tue, Jul 7, 2015 at 1:34 AM, Mark Fasheh wrote: >> >> It runs successfully for several hours and prints out many files which >> are indeed duplicate like this: >> >> Showing 4 identical extents with id 5164bb47 >> Start Length Filename >> 0.0 4.8M"" >> 0.0

Re: running duperemove but no free space gain

2015-07-07 Thread Mordechay Kaganer
B.H. On Tue, Jul 7, 2015 at 9:27 AM, Ryan Bourne wrote: > To clarify, if I did the following: > > # btrfs subvolume create a > # dd bs=1M count=10 if=/dev/urandom of=a/1 > # dd if=a/1 of=a/2 > # btrfs subvolume snapshot a b > > then I have four files containing the same data. a/1, b/1 share exten

Re: running duperemove but no free space gain

2015-07-07 Thread Mordechay Kaganer
B.H. On Tue, Jul 7, 2015 at 4:14 PM, Mordechay Kaganer wrote: > > > The conclusion is: to actually reclaim the duplicated space you have > to include all snapshots that may point to the file. > Tried to dedupe the real data, including all snapshots. Still no free space gain.