On 2021/4/8 下午7:15, riteshh wrote:
Please excuse my silly queries here.
On 21/04/08 04:38PM, Qu Wenruo wrote:
On 2021/4/8 下午4:16, Joe Hermaszewski wrote:
It took a while but I managed to get hold of another one of these
arm32 boards. Very disappointingly this exact "bitflip" is still
pre
Please excuse my silly queries here.
On 21/04/08 04:38PM, Qu Wenruo wrote:
>
>
> On 2021/4/8 下午4:16, Joe Hermaszewski wrote:
> > It took a while but I managed to get hold of another one of these
> > arm32 boards. Very disappointingly this exact "bitflip" is still
> > present (log enclosed).
>
>
On 2021/4/8 下午6:11, Joe Hermaszewski wrote:
Thanks for explaining so patiently, I have a couple more questions if
you have the time:
With the patch I assume that this FS will just refuse to mount on
arm32,
Yes.
If the fs has a chunk beyond 16T, it will be definitely be rejected.
For your c
On 2021/4/8 下午4:16, Joe Hermaszewski wrote:
It took a while but I managed to get hold of another one of these
arm32 boards. Very disappointingly this exact "bitflip" is still
present (log enclosed).
Yeah, we got to the conclusion it's not bitflip, but completely 32bit
limit on armv7.
For AR
It took a while but I managed to get hold of another one of these
arm32 boards. Very disappointingly this exact "bitflip" is still
present (log enclosed).
To summarise, as it's been a while:
- When running scrub, a "page_start" and "eb_start" mismatch is
detected (off by a single bit).
- `btrfs c
On 2020/12/19 下午6:35, Joe Hermaszewski wrote:
Ok, so I managed to get hold of a 64bit machine on which to run btrfs
check. `btrfs check` returns exactly the same output as the armv7 box
(no serious problems) which I suppose is good. `btrfs scrub` also
finds no problems. Boring Logs below.
Wha
Ok, so I managed to get hold of a 64bit machine on which to run btrfs
check. `btrfs check` returns exactly the same output as the armv7 box
(no serious problems) which I suppose is good. `btrfs scrub` also
finds no problems. Boring Logs below.
What I don't quite understand is how the scrub problem
Hi,
I'm having a massive crash of my BTRFS volume.
The server is a HP ProLiant DL380G6 running CentOS on an xfs volume. It
is attached to a HP StorageWorks JBOD device which contains 8 drives,
each formatted as single-volume raid0 devices visible by the OS as
`/dev/sd{b-i}`. `/dev/sdf` is not
On Sat, Jan 05, 2019 at 01:50:36PM +0100, Jos van Roosmalen wrote:
> Hi,
>
> I have a problem with BTRFS. I am running Ubuntu 18.10 and after the
> problems arises, I manually compiled . Problems started to occur when
> I upgraded from 16.04 LTS to 18.04 LTS. After this happened I first
> tried to
Hi,
I have a problem with BTRFS. I am running Ubuntu 18.10 and after the
problems arises, I manually compiled . Problems started to occur when
I upgraded from 16.04 LTS to 18.04 LTS. After this happened I first
tried to upgrade Ubuntu 18.10 and also I manually compiled the latest
btrfs-progs v4.19
On Fri, Feb 23, 2018 at 4:35 PM, Jayashree Mohan
wrote:
> Hi,
>
> [Fsync issue in btrfs]
> In addition to the above, I would like to bring to your notice that :
> After doing a fallocate or fallocate zero_range with keep size option,
> a fsync() operation would have no effect at all. If we crash a
Hi,
[Fsync issue in btrfs]
In addition to the above, I would like to bring to your notice that :
After doing a fallocate or fallocate zero_range with keep size option,
a fsync() operation would have no effect at all. If we crash after the
fsync, on recovery the blocks allocated due to the fallocat
Hi,
On btrfs (as of kernel 4.15), say we fallocate a file with keep_size
option, followed by fdatasync() or fsync(). If we now crash, on
recovery we see a wrong block count and all the blocks allocated
beyond the eof are lost. This bug was reported(xfstest generic/468)
and patched on ext4[1], and
Hello everyone,
Apologies if this is the wrong place, this is my first time posting here.
I just had a crash on one of my Btrfs filesystems, that happened to
prevent it from mounting afterwards. I'd like to help preventing it
from occuring again, or at least to write it there so that other
people
On Thu, Aug 27, 2015 at 4:03 PM, Yasuo Ohgaki wrote:
> Hi developers,
>
> I'm start getting kernel crash/oops from btrfs since 4.1.4.
> https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.1.4
>
> I'm using fedora 22, so I reported this to their bugzilla.
> https://bugzilla.redhat.com/show_bug
Hi developers,
I'm start getting kernel crash/oops from btrfs since 4.1.4.
https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.1.4
I'm using fedora 22, so I reported this to their bugzilla.
https://bugzilla.redhat.com/show_bug.cgi?id=1255509
If you need additional information to fix issue,
t the tags of file "1", etc.). I
>>> will run the non parallelized version of the script which fails as
>>> soon as it can't write out it's "done.txt" file and see if it stops at
>>> the same files.
>>>
>>> In any case, th
etc.). I
>> will run the non parallelized version of the script which fails as
>> soon as it can't write out it's "done.txt" file and see if it stops at
>> the same files.
>>
>> In any case, thanks for the reply and new directions.
>>
>> Dan
zed version of the script which fails as
> soon as it can't write out it's "done.txt" file and see if it stops at
> the same files.
>
> In any case, thanks for the reply and new directions.
>
> Daniel
>
> 2015-05-21 4:49 GMT+02:00 Qu Wenruo :
>>
parallelized version of the script which fails as
soon as it can't write out it's "done.txt" file and see if it stops at
the same files.
In any case, thanks for the reply and new directions.
Daniel
2015-05-21 4:49 GMT+02:00 Qu Wenruo :
>
>
> Original Mes
Original Message
Subject: Re: BTRFS crash after flac tag writing
From: Daniël Sonck
To:
Date: 2015年05月20日 21:54
Extra information:
While I was trying to work around this issue, I found that it rarely
triggers during the whole process. If I resume the process, it seems
Extra information:
While I was trying to work around this issue, I found that it rarely
triggers during the whole process. If I resume the process, it seems
like it just doesn't like a few particular files it needs to tag. As I
can currently live with this state, I have no intention to dive deeper
Hello all,
I ran a modified version of the file system fuzzer
(https://github.com/sughodke/fsfuzzer) for one of the projects I am working,
and at one point I got a possible crash.
I got the following trace on a device with a 32bit kernel 3.14. I have
searched the Bugzilla for this issue,
On 04/24/2014 05:15 AM, Chris Murphy wrote:
>>> Current stable is 3.14.1, I suggest giving 3.13 or 3.14 a shot at this with
>>> -o ro,recovery as a first step and see if it at least mounts.
>>
>> I will. Note that with 12.3, which was the most recent media I had at
>> hand at the time, the FS was
On Apr 23, 2014, at 12:33 PM, Martin Wilck wrote:
> Chris,
>
>> OpenSUSE 12.3 is using kernel 3.7 which is also old for this sort of
>> recovery attempt. Even openSUSE 13.1 is at 3.11.6 which might work in a
>> bind, but if it doesn't, inevitably someone will suggest you use something
>> eve
Chris,
> OpenSUSE 12.3 is using kernel 3.7 which is also old for this sort of recovery
> attempt. Even openSUSE 13.1 is at 3.11.6 which might work in a bind, but if
> it doesn't, inevitably someone will suggest you use something even newer.
Thanks for your reply, I appreciate it a lot.
> Curr
On Apr 16, 2014, at 7:53 AM, Martin Wilck wrote:
>
> The crash happened with a rather old OpenSUSE 12.2 kernel (3.4.11-2.16).
> The user says she was just surfing the web normally when the crash
> occured (no screenshot of the original crash, unfortunately). On the
> next boot, the btrfs root f
Hello,
I have a broken btrfs file system on a laptop.
Debug material is available here:
https://www.dropbox.com/sh/utv8b3qd0do6a04/zTwGQCrN9x
Most importantly, the /home subvolume is lost. All attempts to recover
data from it (btrfs-restore, mount -o recovery, btrfsck) have failed so
far (/hom
On Tue, Feb 04, 2014 at 10:35:06PM +0600, Roman Mamedov wrote:
> On Tue, 4 Feb 2014 16:32:35 +
> Hugo Mills wrote:
>
> > On Tue, Feb 04, 2014 at 10:23:10PM +0600, Roman Mamedov wrote:
> > > Hello,
> > >
> > > My server had a period of instability (PSU-related issues), some lockups,
> > > som
On Tue, 4 Feb 2014 16:32:35 +
Hugo Mills wrote:
> On Tue, Feb 04, 2014 at 10:23:10PM +0600, Roman Mamedov wrote:
> > Hello,
> >
> > My server had a period of instability (PSU-related issues), some lockups,
> > some strange crashes, and some files became corrupted, and perhaps parts of
> > a
On Tue, Feb 04, 2014 at 10:23:10PM +0600, Roman Mamedov wrote:
> Hello,
>
> My server had a period of instability (PSU-related issues), some lockups,
> some strange crashes, and some files became corrupted, and perhaps parts of
> a filesystem too. One BTRFS partition now fails with the following e
Hello,
My server had a period of instability (PSU-related issues), some lockups,
some strange crashes, and some files became corrupted, and perhaps parts of
a filesystem too. One BTRFS partition now fails with the following errors.
On an attempt to make a snapshot:
[ 48.035664] btrfs: corrupt
I am using NFS over brtfs (vanilla 3.8.5) for heavy CoW to clone virtual
disks with sizes 20-50GB. It worked OK for a couple of days, but
yesterday it crashed. Reboot fixed the problem and I do not see any data
corruption. I have a couple of different kdumps, I will include one as
text and attach t
Am Donnerstag, 14. März 2013 schrieb Norbert Scheibner:
> Am 13.03.2013, 12:31 Uhr, schrieb Swâmi Petaramesh :
> > Le 13/03/2013 11:56, Bart Noordervliet a écrit :
> >> USB flash drives are rubbish for any filesystem except FAT32 and then
> >> still only gracefully accept large sequential writes. A
Am 13.03.2013, 12:31 Uhr, schrieb Swâmi Petaramesh :
Le 13/03/2013 11:56, Bart Noordervliet a écrit :
USB flash drives are rubbish for any filesystem except FAT32 and then
still only gracefully accept large sequential writes. A few years ago
I thought it would be a good idea to put the root par
On Thu, Mar 14, 2013 at 12:36:09AM -0600, Russell Coker wrote:
> On Thu, 14 Mar 2013, Chris Mason wrote:
> > Bad key ordering is pretty rare, and it usually means memory
> > corruptions. Are you reproducing this on the same machine or a
> > different one?
>
> I've attached a kernel message log o
Hi Jérôme,
Am Mittwoch, 13. März 2013 schrieb Jérôme Poulin:
> On Tue, Mar 12, 2013 at 10:03 PM, Eric Sandeen wrote:
> > [ 37.176790] BTRFS error (device dm-0) in __btrfs_free_extent:5143:
> > IO failure [ 37.176791] btrfs is forced readonly
> > [ 37.176793] btrfs: run_one_delayed_ref retur
On Thu, 14 Mar 2013, Chris Mason wrote:
> Bad key ordering is pretty rare, and it usually means memory
> corruptions. Are you reproducing this on the same machine or a
> different one?
I've attached a kernel message log of mounting it on another system (which
incidentally has ECC RAM) running t
On Wed, Mar 13, 2013 at 08:03:53AM -0600, Russell Coker wrote:
> On Thu, 14 Mar 2013, Eric Sandeen wrote:
> > > It seems the SSD has bad blocks now, BTRFS seems to abuse SSD disks, I
> > > burnt 1 SSD disk and 2 USB flash drive since I'm using BTRFS, in about
> > > 2 months for each. ddrescue'ing
On Thu, 14 Mar 2013, Eric Sandeen wrote:
> > It seems the SSD has bad blocks now, BTRFS seems to abuse SSD disks, I
> > burnt 1 SSD disk and 2 USB flash drive since I'm using BTRFS, in about
> > 2 months for each. ddrescue'ing the SSD would probably give better
> > chances of recovery and give BTR
On 3/13/13 12:07 AM, Jérôme Poulin wrote:
> On Tue, Mar 12, 2013 at 10:03 PM, Eric Sandeen wrote:
>> [ 37.176790] BTRFS error (device dm-0) in __btrfs_free_extent:5143: IO
>> failure
>> [ 37.176791] btrfs is forced readonly
>> [ 37.176793] btrfs: run_one_delayed_ref returned -5
>>
>
>
> I
Le 13/03/2013 11:56, Bart Noordervliet a écrit :
> USB flash drives are rubbish for any filesystem except FAT32 and then
> still only gracefully accept large sequential writes. A few years ago
> I thought it would be a good idea to put the root partition of a few
> of my small Debian servers on USB
On Wed, Mar 13, 2013 at 6:07 AM, Jérôme Poulin wrote:
> It seems the SSD has bad blocks now, BTRFS seems to abuse SSD disks, I
> burnt 1 SSD disk and 2 USB flash drive since I'm using BTRFS, in about
> 2 months for each.
USB flash drives are rubbish for any filesystem except FAT32 and then
still
On Tue, Mar 12, 2013 at 10:03 PM, Eric Sandeen wrote:
> [ 37.176790] BTRFS error (device dm-0) in __btrfs_free_extent:5143: IO
> failure
> [ 37.176791] btrfs is forced readonly
> [ 37.176793] btrfs: run_one_delayed_ref returned -5
>
It seems the SSD has bad blocks now, BTRFS seems to abus
On 3/12/13 8:38 PM, Russell Coker wrote:
> I have a workstation running the Debian packaged 3.7.1 kernel from 24th
> December last year. After some period of uptime (maybe months) it crashed
> and
> mounted the root filesystem read-only. Now when I boot it the root
> filesystem
> gets mounte
If you care about the data, create a backup if you haven't already
done so. Then you can try btrfsck, maybe you are in luck!
On Wed, Mar 13, 2013 at 2:38 AM, Russell Coker wrote:
> I have a workstation running the Debian packaged 3.7.1 kernel from 24th
> December last year. After some period of
I have a workstation running the Debian packaged 3.7.1 kernel from 24th
December last year. After some period of uptime (maybe months) it crashed and
mounted the root filesystem read-only. Now when I boot it the root filesystem
gets mounted read-only.
I have attached the dmesg output from the
Am Mittwoch, 27. Februar 2013 schrieb Ahmet Inan:
> > Yeah we have a lot of
> >
> > ptr = kmalloc();
> > BUG_ON(ptr);
> >
> > everywhere. I'll fix this one up but I really need to sit down and go
> > through all of them and make sure we do the right thing in all these
> > places. Thanks,
>
> B
> If we're corrupting on abort that is a bug too that needs to be fixed
> too. I've banged on the abort stuff a lot recently when trying to
> make it not panic the box and it appears to work fine. Obviously that
> kind of stuff needs to be tested as well, but so far I haven't seen
> abort corrupt
On Wed, Feb 27, 2013 at 3:10 PM, Ahmet Inan
wrote:
> On Wed, Feb 27, 2013 at 7:26 PM, Josef Bacik wrote:
>> On Wed, Feb 27, 2013 at 07:31:11AM -0700, Ahmet Inan wrote:
>>> > Yeah we have a lot of
>>> >
>>> > ptr = kmalloc();
>>> > BUG_ON(ptr);
>>> >
>>> > everywhere. I'll fix this one up but I r
On Wed, Feb 27, 2013 at 7:26 PM, Josef Bacik wrote:
> On Wed, Feb 27, 2013 at 07:31:11AM -0700, Ahmet Inan wrote:
>> > Yeah we have a lot of
>> >
>> > ptr = kmalloc();
>> > BUG_ON(ptr);
>> >
>> > everywhere. I'll fix this one up but I really need to sit down and go
>> > through
>> > all of them
On Wed, Feb 27, 2013 at 07:31:11AM -0700, Ahmet Inan wrote:
> > Yeah we have a lot of
> >
> > ptr = kmalloc();
> > BUG_ON(ptr);
> >
> > everywhere. I'll fix this one up but I really need to sit down and go
> > through
> > all of them and make sure we do the right thing in all these places.
> >
> Yeah we have a lot of
>
> ptr = kmalloc();
> BUG_ON(ptr);
>
> everywhere. I'll fix this one up but I really need to sit down and go through
> all of them and make sure we do the right thing in all these places. Thanks,
But what would be the right thing to do when you got no memory?
Spinlock un
On Tue, Feb 26, 2013 at 10:22:47PM -0700, Dave Jones wrote:
> Something I've yet to repeat managed to leak a whole bunch of memory
> while I was travelling, and locked up my workstation.
>
> When I got home, this was the last thing printed out before it locked up
> (it did make it into the logs th
Am Mittwoch, 27. Februar 2013 schrieb Dave Jones:
> Something I've yet to repeat managed to leak a whole bunch of memory
> while I was travelling, and locked up my workstation.
>
> When I got home, this was the last thing printed out before it locked up
> (it did make it into the logs thankfully)
Something I've yet to repeat managed to leak a whole bunch of memory
while I was travelling, and locked up my workstation.
When I got home, this was the last thing printed out before it locked up
(it did make it into the logs thankfully) after a bunch of instances of
the oom-killers handywork.
* Liu Bo [2012-11-19 23:27:53 +0800]:
> On Mon, Nov 19, 2012 at 11:07:52AM -0200, Gustavo Padovan wrote:
> > > can you please run
> > > 'gdb fs/btrfs/btrfs.ko' and 'list *block_rsv_release_bytes+0x21' to
> > > check which one is NULL pointer?
> >
> >
> > (gdb) list *block_rsv_release_bytes+0x21
On Mon, Nov 19, 2012 at 11:07:52AM -0200, Gustavo Padovan wrote:
> > can you please run
> > 'gdb fs/btrfs/btrfs.ko' and 'list *block_rsv_release_bytes+0x21' to
> > check which one is NULL pointer?
>
>
> (gdb) list *block_rsv_release_bytes+0x21
> 0x811a83c1 is in block_rsv_release_bytes
>
Hi Liu,
* Liu Bo [2012-11-19 18:32:23 +0800]:
> On Mon, Nov 19, 2012 at 12:55:40AM -0200, Gustavo Padovan wrote:
> > Hi,
> >
> > my system suddenly crashed and gave me this dump:
> >
> > http://imgur.com/oO6S0
> >
> > I checked and there is not btrfs commit in linus' tree since I compiled thi
On Mon, Nov 19, 2012 at 12:55:40AM -0200, Gustavo Padovan wrote:
> Hi,
>
> my system suddenly crashed and gave me this dump:
>
> http://imgur.com/oO6S0
>
> I checked and there is not btrfs commit in linus' tree since I compiled this
> kernel.
>
Hi Gustavo,
It's weird that NULL pointer oops ha
Hi,
my system suddenly crashed and gave me this dump:
http://imgur.com/oO6S0
I checked and there is not btrfs commit in linus' tree since I compiled this
kernel.
Gustavo
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.
On Thu, Aug 02, 2012 at 03:40:03PM +0200, David Sterba wrote:
> On Tue, Jul 31, 2012 at 06:01:04PM -0700, Marc MERLIN wrote:
> > On Tue, Jul 31, 2012 at 11:04:12AM -0700, Marc MERLIN wrote:
> > > My kernel crashed for some other reason, and now I can't mount my btrfs
> > > filesystem.
> > > I don't
On Tue, Jul 31, 2012 at 06:01:04PM -0700, Marc MERLIN wrote:
> On Tue, Jul 31, 2012 at 11:04:12AM -0700, Marc MERLIN wrote:
> > My kernel crashed for some other reason, and now I can't mount my btrfs
> > filesystem.
> > I don't care about the data, it's backed up.
> >
> > I'll compile a 3.5 kernel
> [ 186.277795] Btrfs detected SSD devices, enabling SSD mode
> [ 188.477443] btrfs: unlinked 6 orphans
> [ 188.477451] btrfs: truncated 1 orphans
> [ 411.837015] btrfs: unlinked 13 orphans
> [ 414.373500] btrfs: unlinked 35 orphans
>
> This seems to hint that I lost random files and that I do
On Tue, Jul 31, 2012 at 11:04:12AM -0700, Marc MERLIN wrote:
> My kernel crashed for some other reason, and now I can't mount my btrfs
> filesystem.
> I don't care about the data, it's backed up.
>
> I'll compile a 3.5 kernel, but is there any info you'd like off that
> filesystem to see why btrfs
When I was unsuspending my notebook today btrfs suddenly crashed the
kernel. Unfortunately the only debug output I have are some pictures
made with a shitty mobile phone camera. Maybe they're of some value for
you anyway: http://image.bayimg.com/eaodgaadc.jpg (1.3M, 5000x2500px)
I'm using Ar
On Monday 2012-03-26 03:42, Liu Bo wrote:
>On 03/23/2012 08:07 PM, Jan Engelhardt wrote:
>> Observed on Linux 3.2.9 after the controller/disk flaked in-out.
>> (The world still needs a SCSI error decoding tool to tell normal people
>> what cmd and res are about.)
>>
>
>I'm not that sure if your
On 03/23/2012 08:07 PM, Jan Engelhardt wrote:
> Observed on Linux 3.2.9 after the controller/disk flaked in-out.
> (The world still needs a SCSI error decoding tool to tell normal people
> what cmd and res are about.)
>
I'm not that sure if your 3.2.9-jng4-default build contains this commit or n
Observed on Linux 3.2.9 after the controller/disk flaked in-out.
(The world still needs a SCSI error decoding tool to tell normal people
what cmd and res are about.)
[ 157.732885] device label srv devid 4 transid 11292 /dev/sdf
[ 157.733201] btrfs: disk space caching is enabled
[ 172.936515]
On Sat, Feb 11, 2012 at 03:44:08PM +0100, Daniel Kuhn wrote:
> The mount option "-o recovery" doesn't change anything, the
> segmentation fault still occurs. Any ideas?
Sorry for the hassle, you should be able to get by this by zeroing the
log root.
Run btrfs-zero-log /dev/xxx
-chris
>
> Danie
The mount option "-o recovery" doesn't change anything, the segmentation
fault still occurs. Any ideas?
Daniel
cwillu wrote:
On Wed, Feb 8, 2012 at 4:19 PM, Daniel Kuhn wrote:
After a forced power turn-off the filesystem of my primary boot partition
cannot be mounted anymore,
btrfs crash
On Wed, Feb 8, 2012 at 4:19 PM, Daniel Kuhn wrote:
> After a forced power turn-off the filesystem of my primary boot partition
> cannot be mounted anymore,
> btrfs crashes during the mount process. I'm using OpenSuse 12.1 but I've
> also tried mounting with a newer kernel 3.2.2 (systemrescue cd) a
After a forced power turn-off the filesystem of my primary boot
partition cannot be mounted anymore,
btrfs crashes during the mount process. I'm using OpenSuse 12.1 but I've
also tried mounting with a newer kernel 3.2.2 (systemrescue cd) and with
a usb-converter connected to another PC without s
Hi - this crash occured with Fedora 16 kernel 3.1.5-6.fc16.x86_64. The
message below appeared and the machine locked up with the hard drive on and
the keyboard lights blinking. Btrfs was running with compress-force=zlib on
a software raid md linear array (~5GB), around 50% full.
[
Excerpts from Ravi Pinjala's message of 2010-11-14 12:31:35 -0500:
> I got the following crash on one of my Ceph nodes this morning. I
> don't know how to reproduce it yet; I was just wondering if it was a
> known issue. This is with the latest kernel for Ubuntu 10.10.
>
> Nov 13 19:21:21 alpha ke
I got the following crash on one of my Ceph nodes this morning. I
don't know how to reproduce it yet; I was just wondering if it was a
known issue. This is with the latest kernel for Ubuntu 10.10.
Nov 13 19:21:21 alpha kernel: [19432.396679] [ cut here
]
Nov 13 19:21:22 alp
On Sat, Aug 23, 2008 at 04:37:46PM +0300, Priit Laes wrote:
> Hey!
>
> Got following crash while copying files to btrfs partition with latest
> unstable btrfs.
> Partition itself is a 6GB image residing on ext3 partition.
>
>
> cp used greatest stack depth: 3504 bytes left
> space info full 1
>
Hey!
Got following crash while copying files to btrfs partition with latest
unstable btrfs.
Partition itself is a 6GB image residing on ext3 partition.
cp used greatest stack depth: 3504 bytes left
space info full 1
allocation failed flags 1
[ cut here ]
kernel BUG
at /va
78 matches
Mail list logo
