Greetings,
I would like to ask what what is healthy amount of free space to keep on
each device for btrfs to be happy?
This is how my disk array currently looks like
[root@dennas ~]# btrfs fi usage /raid
Overall:
Device size: 29.11TiB
Device allocated:
Greetings,
I'm running btrfs scrub on my raid each week (is that too often?) and
I'm having a problem that it reports corruption, says it's repaired but
next week reports it again. Here is from dmesg:
$ cat btrfs_error_2017_12_18
[390739.538838] BTRFS warning (device dm-13): checksum error at logi
On , ein wrote:
> On 10/23/2017 10:39 AM, Wolf wrote:
> > [...]
> >
> > Is this and issue somewhere inside btrfs or is disk HW related problem?
>
> Highly unlikely hardware related. According to SMART and dmsg, there's
> no indication which would suggest disk fa
On , Qu Wenruo wrote:
> [27240.680874] perf: interrupt took too long (3952 > 3942), lowering
> kernel.perf_event_max_sample_rate to 50400
> > [30658.875802] BTRFS warning (device dm-12): checksum error at logical
> > 37889245122560 on dev /dev/mapper/data7, sector 2743145096, root 23674,
> > ino
Hi,
I'm having problem with corruption in one file on my disk array. This is
third time it happened (probably). First time I didn't checked the
offending file so I'm not sure but it's likely. Btrfs scrub finds the
corruption, according to both dmesg and it's output it fixes it.
However, next run fi
My OS drive had issues with metadata (disk full even though it wasn't
etc), and so I reinstalled my OS and now I'm learning that my backup
img is bad. What steps should I go through to fix it?
$ sudo mount -o
offset=827808,loop,recovery,ro,nospace_cache,nospace_cache
/data/Backup/Nephele.img
it
further responses before replying to myself again.
---
Eric Wolf
(201) 316-6098
19w...@gmail.com
On Tue, Sep 26, 2017 at 10:41 AM, Eric Wolf <19w...@gmail.com> wrote:
> I accidentally filled my OS drive with a copy of itself? The problem
> is, /data/ is a separate pool from the OS
I accidentally filled my OS drive with a copy of itself? The problem
is, /data/ is a separate pool from the OS drive. And now it looks like
I can't erase it? I don't even know how I got here. All I did was "dd
if=/dev/sda of=/data/Backup/backup-new.img && mv
/data/Backup/backup-new.img /data/Backup
I rolled back my filesystem with 'snapper rollback 81 (or whatever
snapshot it was)' and now when I boot my filesystem is read-only. How
do I fix it?
--
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 a
On Thu, Aug 31, 2017 at 4:11 PM, Hugo Mills wrote:
> On Thu, Aug 31, 2017 at 03:21:07PM -0400, Eric Wolf wrote:
>> I've previously confirmed it's a bad ram module which I have already
>> submitted an RMA for. Any advice for manually fixing the bits?
>
>What I&#
Okay,
I have a hex editor open. Now what? Your instructions seems
straightforward, but I have no idea what I'm doing.
---
Eric Wolf
(201) 316-6098
19w...@gmail.com
On Thu, Aug 31, 2017 at 4:11 PM, Hugo Mills wrote:
> On Thu, Aug 31, 2017 at 03:21:07PM -0400, Eric Wolf wrote:
>> I
I've previously confirmed it's a bad ram module which I have already
submitted an RMA for. Any advice for manually fixing the bits?
Sorry for top leveling, not sure how mailing lists work (again sorry
if this message is top leveled, how do I ensure it's not?)
---
Eric Wolf
(20
Also, I know it was caused by bad RAM and that ram has since been removed.
---
Eric Wolf
(201) 316-6098
19w...@gmail.com
On Thu, Aug 31, 2017 at 2:33 PM, Hugo Mills wrote:
> On Thu, Aug 31, 2017 at 01:53:58PM -0400, Eric Wolf wrote:
>> I'm having issues with a bad block(?)
disk byte 402717990912 nr 8192
extent data offset 0 nr 4096 ram 8192
extent compression 0
item 152 key (890558 EXTENT_DATA 1118208) itemoff 6645 itemsize 53
extent data disk byte 402721890304 nr 20480
extent data offset 0 nr 16384 ram 20480
extent compression 0
---
Eric Wolf
(201) 316-6098
19w
I'm having issues with a bad block(?) on my root ssd.
dmesg is consistently outputting "BTRFS critical (device sda2):
corrupt leaf, bad key order: block=293438636032, root=1, slot=11"
"btrfs scrub stat /" outputs "scrub status for b2c9ff7b-[snip]-48a02cc4f508
scrub started at Wed Aug 30 11:51:49
Hi
As the fs in question is my root, I tried the following using a live usb
stick of a xubuntu 16.10:
Checking filesystem on /dev/sdb1
UUID: 122ecca7-9804-4c8a-b4ed-42fd6c6bbe7a
checking extents [o]
checking free space cache [.]
checking fs roots [o]
found 40577679360 bytes used err is 0
tot
Hi all
I have a problem with incremental snapshot send receive in btrfs. May be
my google-fu is weak, but I couldn't find any pointers, so here goes.
A few words about my setup first:
I have multiple clients that back up to a central server. All clients
(and the server) are running a (K)Ub
problem?
Greetings
Wolf Bublitz--
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
18 matches
Mail list logo
