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.
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
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
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
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
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
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
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
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
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
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
&
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?
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
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
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
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
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.
17 matches
Mail list logo