On Sat, Apr 17, 2021 at 4:03 PM Florian Franzeck wrote:
>
> Dear users,
>
> I need help to recover from a btrfs error after a power cut
>
> btrfs-progs v5.4.1
>
> Linux banana 5.4.0-72-generic #80-Ubuntu SMP Mon Apr 12 17:35:00 UTC
> 2021 x86_64 x86_64 x86_64
Dear users,
I need help to recover from a btrfs error after a power cut
btrfs-progs v5.4.1
Linux banana 5.4.0-72-generic #80-Ubuntu SMP Mon Apr 12 17:35:00 UTC
2021 x86_64 x86_64 x86_64 GNU/Linux
dmesg output:
[ 30.330824] BTRFS info (device md1): disk space caching is enabled
On Fri, 2 Apr 2021 22:46:25 +0200
Thomas <74cmo...@gmail.com> wrote:
> Hi,
>
> I finished repartition of devices /dev/sda + /dev/sdb now.
> On both devices the first partition is equal in size:
> $ sudo fdisk -l /dev/sda
> Festplatte /dev/sda: 238,47 GiB, 256060514304 Bytes, 500118192 Sektoren
>
Hi,
I finished repartition of devices /dev/sda + /dev/sdb now.
On both devices the first partition is equal in size:
$ sudo fdisk -l /dev/sda
Festplatte /dev/sda: 238,47 GiB, 256060514304 Bytes, 500118192 Sektoren
Festplattenmodell: SanDisk SD8SBAT2
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sekt
Hello Chris,
many thanks for your analysis.
I'm not sure how to proceed in order to fix this error.
Obviously both devices, sda and sdb, are not partitioned 100%
correct/optimal.
Therefore I consider to restart from scratch, means
- creating a file backup of OS
- deleting any partion on sda a
On Sat, Mar 13, 2021 at 5:22 AM Thomas <74cmo...@gmail.com> wrote:
> Gerät Boot Anfang Ende Sektoren Größe Kn Typ
> /dev/sdb1 2048 496093750 496091703 236,6G 83 Linux
> However the output of btrfs insp dump-s is different:
> thomas@pc1-desktop:~
> $ sudo btrfs insp dump-s /de
gt; Hello,
>>
>> I have observed this error messages in systemd journal:
>> BTRFS error (device sda1): bdev /dev/sdb1 errs: wr 2702175, rd 2719033,
>> flush 0, corrupt 6, gen 0
>>
>> Here are the bottom lines of journalctl -xb:
>> ?r 12 08:30:41 pc1-deskto
,
>
> I have observed this error messages in systemd journal:
> BTRFS error (device sda1): bdev /dev/sdb1 errs: wr 2702175, rd 2719033,
> flush 0, corrupt 6, gen 0
>
> Here are the bottom lines of journalctl -xb:
> ?r 12 08:30:41 pc1-desktop kernel: atte
ond end of device
sdb1: rw=524288, want=496544128, limit=496091703
[ 20.685798] attempt to access beyond end of device
sdb1: rw=2049, want=496544128, limit=496091703
[ 20.685804] BTRFS error (device sda1): bdev /dev/sdb1 errs: wr
2701996, rd 2718862, flush 0, corrup
Hello,
I have observed this error messages in systemd journal:
BTRFS error (device sda1): bdev /dev/sdb1 errs: wr 2702175, rd 2719033,
flush 0, corrupt 6, gen 0
Here are the bottom lines of journalctl -xb:
är 12 08:30:41 pc1-desktop kernel: attempt to access beyond end of device
On 2021/3/8 下午6:02, chil L1n wrote:
Hi Qu,
Thanks for some explanation.
Personally, I prefer binary to compare bit-level changes.
Actually, I also miscounted. I count 3 bit flips.
Yes, you're right, xor also returns 3 bits flips.
But the point is not about directly comparing the two key of
> chill
> >>
> >>
> >> On Mon, Mar 8, 2021 at 9:41 AM Johannes Thumshirn
> >> wrote:
> >>>
> >>> On 06/03/2021 10:11, chil L1n wrote:
> >>>> [211.868642] BTRFS critical (device sda4): corrupt leaf: root=258
> >>>> b
276800)
current (256703 108 1310720)
[211.868650] BTRFS error (device sda4): block=250975895552 write
time tree block corruption detected
This /might/ be a memory bitflip:
3276800 = 0b110010
1310720 = 0b10100
I guess the highest bit did flip so it should hav
mshirn
wrote:
On 06/03/2021 10:11, chil L1n wrote:
[211.868642] BTRFS critical (device sda4): corrupt leaf: root=258
block=250975895552 slot=78, bad key order, prev (256703 108 3276800)
current (256703 108 1310720)
[2555511.868650] BTRFS error (device sda4): block=250975895552 write
time tr
chill
On Mon, Mar 8, 2021 at 9:41 AM Johannes Thumshirn
wrote:
On 06/03/2021 10:11, chil L1n wrote:
[211.868642] BTRFS critical (device sda4): corrupt leaf: root=258
block=250975895552 slot=78, bad key order, prev (256703 108 3276800)
current (256703 108 1310720)
[211.868650] BTRFS err
wrote:
>
> On 06/03/2021 10:11, chil L1n wrote:
> > [211.868642] BTRFS critical (device sda4): corrupt leaf: root=258
> > block=250975895552 slot=78, bad key order, prev (256703 108 3276800)
> > current (256703 108 1310720)
> > [211.868650] BTRFS error (dev
On 06/03/2021 10:11, chil L1n wrote:
> [211.868642] BTRFS critical (device sda4): corrupt leaf: root=258
> block=250975895552 slot=78, bad key order, prev (256703 108 3276800)
> current (256703 108 1310720)
> [2555511.868650] BTRFS error (device sda4): block=250975895552 write
error (device sda4): block=250975895552 write
time tree block corruption detected
[211.916529] BTRFS: error (device sda4) in
btrfs_commit_transaction:2279: errno=-5 IO failure (Error while
writing out transaction)
[211.916544] BTRFS info (device sda4): forced readonly
[211.916547] BTRFS
On Thu, Feb 18, 2021 at 08:46:02PM +, Samir Benmendil wrote:
> On Feb 17, 2021 at 16:56, Samir Benmendil wrote:
> > On 17 February 2021 13:45:02 GMT+00:00, Hugo Mills
> > wrote:
> > > On Wed, Feb 17, 2021 at 01:26:40PM +, Samir Benmendil wrote:
> > > > Any advice on what to do next would b
On Feb 17, 2021 at 16:56, Samir Benmendil wrote:
On 17 February 2021 13:45:02 GMT+00:00, Hugo Mills
wrote:
On Wed, Feb 17, 2021 at 01:26:40PM +, Samir Benmendil wrote:
Any advice on what to do next would be appreciated.
The first thing to do is run memtest for a while (I'd usually
reco
vice dm-0): corrupt leaf: root=2 block=711870922752
>> slot=275, bad key order, prev (693626798080 182 702129324032) current
>> (693626798080 182 701861986304)
>>BTRFS info (device dm-0): leaf 711870922752 gen 610518 total ptrs 509
>> free space 276 owner 2
>>BT
prev (693626798080 182 702129324032) current
> (693626798080 182 701861986304)
>BTRFS info (device dm-0): leaf 711870922752 gen 610518 total ptrs 509 free
> space 276 owner 2
>BTRFS error (device dm-0): block=711870922752 write time tree
> block corruption detec
dm-0): leaf 711870922752 gen 610518 total ptrs 509 free
space 276 owner 2
BTRFS error (device dm-0): block=711870922752 write time tree block corruption detected
BTRFS: error (device dm-0) in btrfs_commit_transaction:2376: errno=-5 IO
failure (Error while writing out transaction)
BTRFS
On 8/22/19 12:32 AM, Qu Wenruo wrote:
>>> Then I'd recommend to do regular rescue procedure:
>>> - Try that skip_bg patchset if possible
>>> This provides the best salvage method so far, full subvolume
>>> available, although needs out-of-tree patches.
>>> https://patchwork.kernel.org/projec
On 9/4/19 6:48 PM, Josef Bacik wrote:
On Wed, Sep 04, 2019 at 04:02:24PM +0800, Hongzhi, Song wrote:
Hi ,
*Kernel:*
After v5.2-rc1, qemux86-64
make -j40 ARCH=x86_64 CROSS_COMPILE=x86-64-gcc
use qemu to bootup kernel
*Reproduce:*
There is a test case failed on btrfs b
On Wed, Sep 04, 2019 at 04:02:24PM +0800, Hongzhi, Song wrote:
> Hi ,
>
>
> *Kernel:*
>
> After v5.2-rc1, qemux86-64
>
> make -j40 ARCH=x86_64 CROSS_COMPILE=x86-64-gcc
> use qemu to bootup kernel
>
>
> *Reproduce:*
>
> There is a test case failed on btrfs but success on other
Hi Nikolay,
>
There were multiple fixes from Josef recently improving btrfs enospc
handling with tiny filesystems (which is generally not the targeted use
case of btrfs). The code lives in
https://github.com/kdave/btrfs-devel/commits/misc-next should you want
to test it. Otherwise re-test after
Hi ,
*Kernel:*
After v5.2-rc1, qemux86-64
make -j40 ARCH=x86_64 CROSS_COMPILE=x86-64-gcc
use qemu to bootup kernel
*Reproduce:*
There is a test case failed on btrfs but success on other
fs(ext4,ext3), see attachment.
Download attachments:
gcc test.c -o myout
ule loading by
>>> setting 'ecc_enable_override'.
>>> (Note that use of the override may cause unknown side
>>> effects.)
>> Not sure what the ECC part is doing, but it repeats quite some times.
>> I'd assume it's unre
e ECC part is doing, but it repeats quite some times.
> I'd assume it's unrelated though.
>
Not sure either. I've not got ECC RAM. Motherboard is capable I think.
> [...]
>> [ 142.507291] BTRFS error (device dm-2): parent transid verify failed
>> on
On 2019/8/21 下午4:05, Peter Chant wrote:
> hings
> On 8/20/19 10:59 PM, Chris Murphy wrote:
>> On Tue, Aug 20, 2019 at 3:10 PM Peter Chant wrote:
>>>
>>> Chasing IO errors. BTRFS: error (device dm-2) in
>>> btrfs_run_delayed_refs:2907: errno=-5 IO failu
hings
On 8/20/19 10:59 PM, Chris Murphy wrote:
> On Tue, Aug 20, 2019 at 3:10 PM Peter Chant wrote:
>>
>> Chasing IO errors. BTRFS: error (device dm-2) in
>> btrfs_run_delayed_refs:2907: errno=-5 IO failure
>>
>>
>> I've just had an odd one.
>
On 2019/8/21 上午4:36, Peter Chant wrote:
> Chasing IO errors. BTRFS: error (device dm-2) in
> btrfs_run_delayed_refs:2907: errno=-5 IO failure
Full dmesg please.
This output should include a lot of info, like stack dump and several
different error message.
One single line with least amo
On 8/20/19 10:59 PM, Chris Murphy wrote:
> On Tue, Aug 20, 2019 at 3:10 PM Peter Chant wrote:
>>
>> Chasing IO errors. BTRFS: error (device dm-2) in
>> btrfs_run_delayed_refs:2907: errno=-5 IO failure
>>
>>
>> I've just had an odd one.
>>
&g
On Tue, Aug 20, 2019 at 3:10 PM Peter Chant wrote:
>
> Chasing IO errors. BTRFS: error (device dm-2) in
> btrfs_run_delayed_refs:2907: errno=-5 IO failure
>
>
> I've just had an odd one.
>
> Over the last few days I've noticed a file system blocking, if th
Chasing IO errors. BTRFS: error (device dm-2) in
btrfs_run_delayed_refs:2907: errno=-5 IO failure
I've just had an odd one.
Over the last few days I've noticed a file system blocking, if that is
the correct term, and this morning go read only. This resulted in a lot
of check
Hello!
I have a problem with btrfs device.
Shows 355Gb free space.
Done scrub on that.
It shows that there is no space left on device.
Doing simple operations (mkdir, touch, find) are extremely slow.
Checking btrfsck show add_data_backref error (see below).
Do you think I could do : btrfs c
ormance of multiuser system.
test-url: https://sourceforge.net/projects/aimbench/files/aim-suite7/
on test machine: 40 threads Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz with 384G
memory
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
[ 25.285253] BTRFS err
Thanks Dan! You are right. Will fix it.
Anand
On 10/13/2017 04:39 AM, Dan Carpenter wrote:
Hello Anand Jain,
The patch 1eea2715ca9b: "btrfs: error out if
btrfs_attach_transaction() fails" from Sep 28, 2017, leads to the
following static checker warning:
fs/btrfs/volu
Hello Anand Jain,
The patch 1eea2715ca9b: "btrfs: error out if
btrfs_attach_transaction() fails" from Sep 28, 2017, leads to the
following static checker warning:
fs/btrfs/volumes.c:2502 btrfs_init_new_device()
error: 'trans' dereferencing possible ERR_PTR()
On Mon, Oct 9, 2017 at 1:22 AM, Nick Gilmour wrote:
>> I don't see a 'btrfs filesystem resize' command in your sequence. Did
>> you actually resize the file system before you resized the underlying
>> (virtual) block device?
>
>
> OK. I guess, this is it. I didn't do any 'btrfs filesystem resize'
> I don't see a 'btrfs filesystem resize' command in your sequence. Did
> you actually resize the file system before you resized the underlying
> (virtual) block device?
OK. I guess, this is it. I didn't do any 'btrfs filesystem resize' .
The guides I was following didn't mention something like th
On Sun, Oct 8, 2017 at 4:39 PM, Nick Gilmour wrote:
> Thanks for the reply!
>
> For conversion I used this command:
> $ vboxmanage internalcommands converttoraw mydisk.vdi mydisk.img
>
> and for resizing this one:
> $ qemu-img resize mydisk.img 150G
>
> Is there something I can do to fix this or a
ported the VM
>> into VMM and it started normally but an upgrade failed. I've rebooted
>> and got only a blue screen something like a BSOD on Windows. I've
>> changed into a terminal and now this error appears constantly:
>>
>> "BTRFS error (device vda1
I've rebooted
> and got only a blue screen something like a BSOD on Windows. I've
> changed into a terminal and now this error appears constantly:
>
> "BTRFS error (device vda1): couldn't get super buffer head for bytenr x"
The error implies that it failed t
ve
changed into a terminal and now this error appears constantly:
"BTRFS error (device vda1): couldn't get super buffer head for bytenr x"
I can stop it shortly with Ctrl-C and enter a command. With startx I
can see my desktop in blue color with some icons in it and nothing
mo
btrfs_init_new_device() calls btrfs_attach_transaction() to
commit sys chunks, and it should error out if it fails.
Signed-off-by: Anand Jain
Reviewed-by: Qu Wenruo
---
v4: make this patch as part of this set.
avoid double mutext unlock.
v3: not part of this set
v2: patch did not exist
v1: p
On Sun, Sep 10, 2017 at 05:22:14PM -0700, Marc MERLIN wrote:
> On Sun, Sep 10, 2017 at 01:16:26PM +, Josef Bacik wrote:
> > Great, if the free space cache is fucked again after the next go
> > around then I need to expand the verifier to watch entries being added
> > to the cache as well. Than
On Sun, Sep 10, 2017 at 01:16:26PM +, Josef Bacik wrote:
> Great, if the free space cache is fucked again after the next go
> around then I need to expand the verifier to watch entries being added
> to the cache as well. Thanks,
Well, I copied about 1TB of data, and nothing happened.
So it se
Great, if the free space cache is fucked again after the next go around then I
need to expand the verifier to watch entries being added to the cache as well.
Thanks,
Josef
Sent from my iPhone
> On Sep 10, 2017, at 9:14 AM, Marc MERLIN wrote:
>
>> On Sun, Sep 10, 2017 at 03:12:16AM +, Jo
On Sun, Sep 10, 2017 at 03:12:16AM +, Josef Bacik wrote:
> Ok mount -o clear_cache, umount and run fsck again just to make sure. Then
> if it comes out clean mount with ref_verify again and wait for it to blow up
> again. Thanks,
Ok, just did the 2nd fsck, came back clean after mount -o c
Ok mount -o clear_cache, umount and run fsck again just to make sure. Then if
it comes out clean mount with ref_verify again and wait for it to blow up
again. Thanks,
Josef
Sent from my iPhone
> On Sep 9, 2017, at 10:37 PM, Marc MERLIN wrote:
>
>> On Sat, Sep 09, 2017 at 10:56:14PM +,
On Sat, Sep 09, 2017 at 10:56:14PM +, Josef Bacik wrote:
> Well that's odd, a block allocated on disk is in the free space cache. Can I
> see the full output of the fsck? I want to make sure it's actually getting
> to the part where it checks the free space cache. If it does then I'll have
01.787169] kthread+0xfb/0x100
> [318401.797769] ? init_completion+0x24/0x24
> [318401.810718] ret_from_fork+0x25/0x30
> [318401.822588] Code: 85 c0 41 89 c4 79 60 48 8b 43 60 f0 0f ba a8 d8 16 00
> 00 02 72 35 41 83 fc fb 74 13 44 89 e6 48 c7 c7 27 3f af ae e8 81 5d e1 ff
> <0f
<0f> ff
eb 1c f6 05 2a da ab 00 04 74 13 48 8b 7b 60 44 89 e2 48
[318401.881182] ---[ end trace 47464f1fcc4796c5 ]---
[318401.896818] BTRFS: error (device dm-2) in btrfs_run_delayed_refs:3015:
errno=-17 Object already exists
[318401.925978] BTRFS info (device dm-2): forced readonly
[3184
Alright I just reworked the build tree ref stuff and tested it to make sure it
wasn’t going to give false positives again. Apparently I had only ever used
this with very basic existing fs’es and nothing super complicated, so it was
just broken for anything complex. I’ve pushed it to my tree, y
Ok this output looked fishy and so I went and tested it on my box again. It
looks like I wasn't testing modifying a snapshot with an existing fs so I never
saw these errors, but I see them as well. I definitely fucked the building of
the initial ref tree. It's too late tonight for me to rewor
On Sun, Sep 03, 2017 at 05:33:33PM +, Josef Bacik wrote:
> Alright pushed, sorry about that.
I'm reasonably sure I'm running the new code, but still got this:
[ 2104.336513] Dropping a ref for a root that doesn't have a ref on the block
[ 2104.358226] Dumping block entry [115253923840 155648]
Alright pushed, sorry about that.
Josef
Sent from my iPhone
> On Sep 3, 2017, at 10:42 AM, Marc MERLIN wrote:
>
>> On Sun, Sep 03, 2017 at 02:38:57PM +, Josef Bacik wrote:
>> Oh yeah you need CONFIG_STACKTRACE turned on, otherwise this is going to be
>> difficult ;). Thanks,
>
> Right,
Jesus Christ I misspelled it, I'll fix it up when I get home. Thanks,
Josef
Sent from my iPhone
> On Sep 3, 2017, at 10:42 AM, Marc MERLIN wrote:
>
>> On Sun, Sep 03, 2017 at 02:38:57PM +, Josef Bacik wrote:
>> Oh yeah you need CONFIG_STACKTRACE turned on, otherwise this is going to be
>
On Sun, Sep 03, 2017 at 02:38:57PM +, Josef Bacik wrote:
> Oh yeah you need CONFIG_STACKTRACE turned on, otherwise this is going to be
> difficult ;). Thanks,
Right, except that I thought I did:
saruman:/usr/src/linux-btrfs/btrfs-next# grep STACKTRACE .config
CONFIG_STACKTRACE_SUPPORT=y
CO
Oh yeah you need CONFIG_STACKTRACE turned on, otherwise this is going to be
difficult ;). Thanks,
Josef
Sent from my iPhone
> On Sep 3, 2017, at 10:31 AM, Marc MERLIN wrote:
>
>> On Sun, Sep 03, 2017 at 03:26:34AM +, Josef Bacik wrote:
>> I was looking through the code for other ways to
On Sun, Sep 03, 2017 at 03:26:34AM +, Josef Bacik wrote:
> I was looking through the code for other ways to cut down memory usage when I
> noticed we only catch improper re-allocations, not adding another ref for
> metadata which is what I suspect your problem is. I added another patch and
I was looking through the code for other ways to cut down memory usage when I
noticed we only catch improper re-allocations, not adding another ref for
metadata which is what I suspect your problem is. I added another patch and
pushed it out, sorry for the churn.
Josef
Sent from my iPhone
>
On Sun, Sep 03, 2017 at 12:30:07AM +, Josef Bacik wrote:
> My bad, I forgot I don't dynamically allocate the stack trace space so my
> patch did nothing, I blame the children for distracting me. I've dropped
> allocating the action altogether for the on disk stuff, that should
> dramaticall
My bad, I forgot I don't dynamically allocate the stack trace space so my patch
did nothing, I blame the children for distracting me. I've dropped allocating
the action altogether for the on disk stuff, that should dramatically reduce
the memory usage. You can just do a git pull since I made a
On Sat, Sep 02, 2017 at 04:52:20PM +, Josef Bacik wrote:
> Oops, ok I've updated my tree so we don't save the stack trace of the initial
> scan, which we don't need anyway. That should save a decent amount of memory
> in your case. It was an in place update so you'll need to blow away your
I've just had this happen for the 3rd time in 4 days. I wasn't
suibscribed to the list so couldn't reply to the existing thread but
here it is http://www.spinics.net/lists/linux-btrfs/msg68662.html
I can do some limited testing. It's my main dev machine though..
On Sat, Sep 2, 2017 at 10:52 AM
Oops, ok I've updated my tree so we don't save the stack trace of the initial
scan, which we don't need anyway. That should save a decent amount of memory
in your case. It was an in place update so you'll need to blow away your local
branch and pull the new one to get the new code. Thanks,
J
On Fri, Sep 01, 2017 at 11:01:30PM +, Josef Bacik wrote:
> You'll be fine, it's only happening on the one fs right? That's 13gib of
> metadata with checksums and all that shit, it'll probably look like 8 or 9gib
> of ram worst case. I'd mount with -o ref_verify and check the slab amount in
You'll be fine, it's only happening on the one fs right? That's 13gib of
metadata with checksums and all that shit, it'll probably look like 8 or 9gib
of ram worst case. I'd mount with -o ref_verify and check the slab amount in
/proc/meminfo to get an idea of real usage. Once the mount is fin
On Thu, Aug 31, 2017 at 05:48:23PM +, Josef Bacik wrote:
> We are using 4.11 in production at fb with backports from recent (a month
> ago?) stuff. I’m relatively certain nothing bad will happen, and this branch
> has the most recent fsync() corruption fix (which exists in your kernel so
>
We are using 4.11 in production at fb with backports from recent (a month ago?)
stuff. I’m relatively certain nothing bad will happen, and this branch has the
most recent fsync() corruption fix (which exists in your kernel so it’s not
new). That said if you are uncomfortable I can rebase this
On Thu, Aug 31, 2017 at 02:52:56PM +, Josef Bacik wrote:
> Hello,
>
> Sorry I really thought I could accomplish this with BPF, but ref tracking is
> just too complicated to work properly with BPF. I forward ported my ref
> verification patch to the latest kernel, you can find it in the btrf
Hello,
Sorry I really thought I could accomplish this with BPF, but ref tracking is
just too complicated to work properly with BPF. I forward ported my ref
verification patch to the latest kernel, you can find it in the btrfs-readdir
branch of my btrfs-next tree here
git://git.kernel.org/pub/
f 44 00 00 55 48 89 e5 41 55 41 54 53 48 8b
47
[ +0.16] ---[ end trace 9a66996bbd24d74d ]---
[ +0.02] BTRFS: error (device sdg1) in
btrfs_run_delayed_refs:2971: errno=-17 Object already exists
[ +0.02] BTRFS info (device sdg1): forced readonly
[ +0.001029] BTRFS error (device sdg1):
On Tue, Aug 29, 2017 at 06:22:38PM +, Josef Bacik wrote:
> How much metadata do you have on this fs? I was going to hold everything in
> bpf hash trees, but I’m worried we’ll hit collisions and then the tracing
> will be useless. If it’s too big I’ll have to dump everything to userspace
>
How much metadata do you have on this fs? I was going to hold everything in
bpf hash trees, but I’m worried we’ll hit collisions and then the tracing will
be useless. If it’s too big I’ll have to dump everything to userspace and let
python take care of keeping everything in memory, so if you h
Alright I’ll figure out a way to differentiate between the fs’s, but being able
to scan the fs before it’s mounted was the hardest part so that’s perfect.
I’ll get something written up and tested today to make sure it won’t spit out
false positives and send it to you this afternoon or tomorrow.
On Tue, Aug 29, 2017 at 02:30:19PM +, Josef Bacik wrote:
> Sorry Marc, I’ll wire up a bcc script to try and catch when this
> happens. In order for it to work it’ll need to read the extent tree in
> before you mount the fs, is that something you’ll be able to swing or is
> this your root fs?
nt, or at
> > least not as benign as a race condition
> > between snapshot creation and deletion for those who do hourly snapshot
> > rotations like me.
>
> I just finished 2 check repairs, one with each mode, they both come back
> clean.
> Yet my FS still remounts read
condition
> > between snapshot creation and deletion for those who do hourly snapshot
> > rotations like me.
>
> I just finished 2 check repairs, one with each mode, they both come back
> clean.
> Yet my FS still remounts read only with the same
> BTRFS: error (device dm-2
On 2017年08月18日 11:49, Qu Wenruo wrote:
On 2017年08月18日 11:13, Zirconium Hacker wrote:
I hope "Reply All" is the right option here. Again, first time
interacting with a mailing list. Google said that was what to do.
You're doing quite well, and yes, Reply All is the right option.
I have
THANK YOU ALL! I just had to truncate the first 1.5 KiB of the image
file to get the offsets right (God knows why), but I could then get
the btrfs driver to recognize it, and I could MOUNT THE FILESYSTEM!
I'm going to run btrfs check on it, free some space on it, PROPERLY
remove the extra device,
The image doesn't have a valid superblock. I'm really confused as to
how that could've happened.
On Fri, Aug 18, 2017 at 7:21 PM, Qu Wenruo wrote:
>
>
> On 2017年08月19日 05:52, Zirconium Hacker wrote:
>>
>> Ok, so since it's clear now that I need that 5 GB device to be
>> present... I found the im
On 2017年08月19日 05:52, Zirconium Hacker wrote:
Ok, so since it's clear now that I need that 5 GB device to be
present... I found the image file. But how do I get BTRFS to
recognize the image as a device?
# losetup -f
Remember the loop*, here use /dev/loop1 as example.
# losetup /dev/loop1
#
Ok, so since it's clear now that I need that 5 GB device to be
present... I found the image file. But how do I get BTRFS to
recognize the image as a device? I have zero experience with
multi-device systems. Setting it up as a loop device doesn't fix
mounting, and wipefs doesn't detect the BTRFS
On Fri, Aug 18, 2017 at 2:47 AM, Zirconium Hacker wrote:
> I vaguely remember following this guide at some point:
> http://marc.merlins.org/perso/btrfs/post_2014-05-04_Fixing-Btrfs-Filesystem-Full-Problems.html
> -- specifically the "Balance cannot run because the filesystem is
> full" part. Thi
On 2017年08月18日 18:20, Zirconium Hacker wrote:
# ./btrfs-debug-tree -b 131072 /dev/sda4
https://pastebin.com/TDa0GuqB
At least this output explains everything.
( although the result may not make you happy )
Check this:
item 59 key (FIRST_CHUNK_TREE CHUNK_ITEM 62351474688) itemoff 11447
# ./btrfs-debug-tree -b 131072 /dev/sda4
https://pastebin.com/TDa0GuqB
# ./btrfs-debug-tree -b 61809344512 /dev/sda4
btrfs-progs v4.12-dirty
bytenr mismatch, want=61809344512, have=0
Couldn't read tree root
bytenr mismatch, want=61809344512, have=0
ERROR: failed to read 61809344512
# ./btrfs-debug-
Would you please try this patch?
https://patchwork.kernel.org/patch/9908173/
This should allow btrfs-debug-tree to output tree block even tree root
is corrupted.
You could apply it on lasted master branch (tagged as v4.12).
Then re-execute the following command (with patched btrfs-progs):
# bt
$ sudo btrfs check -r 108544 /dev/sda4
parent transid verify failed on 108544 wanted 325966 found 325709
parent transid verify failed on 108544 wanted 325966 found 325709
Ignoring transid failure
bytenr mismatch, want=61352312832, have=0
Couldn't setup device tree
ERROR: cannot open fil
On 2017年08月18日 17:08, Zirconium Hacker wrote:
I already ran that earlier, here's the pastebin: https://pastebin.com/KGB8nVRA
Running debug-tree on all 1084 of them (I guess that was unnecessary)
gave the same errors every time:
bytenr mismatch, want=61809344512, have=0
Couldn't read tree root
I already ran that earlier, here's the pastebin: https://pastebin.com/KGB8nVRA
Running debug-tree on all 1084 of them (I guess that was unnecessary)
gave the same errors every time:
bytenr mismatch, want=61809344512, have=0
Couldn't read tree root
ERROR: unable to open /dev/sda4
On Fri, Aug 18, 2
On 2017年08月18日 16:47, Zirconium Hacker wrote:
$ sudo btrfs-debug-tree -b 131072 /dev/sda4
btrfs-progs v4.12
bytenr mismatch, want=61809344512, have=0
Couldn't read tree root
ERROR: unable to open /dev/sda4
I think this can be improved for case like this.
I'll try to submit a patch to enhance
$ sudo btrfs-debug-tree -b 131072 /dev/sda4
btrfs-progs v4.12
bytenr mismatch, want=61809344512, have=0
Couldn't read tree root
ERROR: unable to open /dev/sda4
Mounting with degraded,ro does not fix the multi-device issue. The
system was never really intended to have a second device, though:
$ s
On 2017年08月18日 15:17, Zirconium Hacker wrote:
I checked my fstab, and my mount options for that partition are:
nodev,nosuid (so no discard).
As far as I remember, I had some issues converting from ext4 with
existing tools (I think that was on Debian so the tools were likely
older) so I did a ma
I checked my fstab, and my mount options for that partition are:
nodev,nosuid (so no discard).
As far as I remember, I had some issues converting from ext4 with
existing tools (I think that was on Debian so the tools were likely
older) so I did a manual conversion backup, wipe, copy files back).
$
On Thu, Aug 17, 2017 at 4:42 PM, Qu Wenruo wrote:
> BTW are you using discard mount option? Sometimes it can cause problem.
OP did not say if it was using discard mount option; but did say some
time before this (I'm not sure how recent) he had used fstrim. The
firmware for this SSD model is curr
On 2017年08月18日 11:13, Zirconium Hacker wrote:
I hope "Reply All" is the right option here. Again, first time
interacting with a mailing list. Google said that was what to do.
You're doing quite well, and yes, Reply All is the right option.
I have found no I/O errors in dmesg -- at least,
1 - 100 of 255 matches
Mail list logo
