From: Sergei Trofimovich
Reproducer:
mount /dev/ubda /mnt
mount -oremount,thread_pool=42 /mnt
Gives a crash:
? btrfs_workqueue_set_max+0x0/0x70
btrfs_resize_thread_pool+0xe3/0xf0
? sync_filesystem+0x0/0xc0
? btrfs_resize_thread_pool+0x0/0xf0
btrfs_remount+0x1d2/0x570
Hi there,
Machine got rebooted while scrub was in process, and now it looks like a scrub
zombie...
How do I restore this to a normal non-zombie state ?
root@zafu:~# btrfs scrub status /
scrub status for 13c87f57-3a85-4daf-a4bf-ba777407c169
scrub started at Mon Apr 7 09:49:48 2014, runn
Sorry, I meant kernel 3.13 :-)
Linux zafu 3.13.8-1-ARCH #1 SMP PREEMPT Tue Apr 1 12:19:51 CEST 2014 x86_64
GNU/Linux
Le lundi 7 avril 2014 10:32:04 Swâmi Petaramesh a écrit :
> Hi there,
>
> Machine got rebooted while scrub was in process, and now it looks like a
> scrub zombie...
>
> How do
On Mon, Apr 07, 2014 at 10:32:04AM +0200, Swâmi Petaramesh wrote:
> Hi there,
>
> Machine got rebooted while scrub was in process, and now it looks like a
> scrub
> zombie...
>
> How do I restore this to a normal non-zombie state ?
There's a status file in /var/lib/btrfs (at least, it's som
Le lundi 7 avril 2014 10:02:36 Hugo Mills a écrit :
>There's a status file in /var/lib/btrfs (at least, it's somewhere
> near there -- I think that's it, though). Delete that
# rm /var/lib/btrfs/scrub.status.13c87f57-3a85-4daf-a4bf-ba777407c169
> and you should be OK.
I'm OK, thanks ! :-)
>
Scenario: I had a subvolume with compression disabled and with many snapshots.
Then I decided to compress it retroactively with the following commands:
btrfs filesystem defragment -r -v -czlib /path
find /path -xdev -type d -print -exec btrfs filesystem
defragment -czlib '{}' \;
a
On Fri, 04 Apr 2014 08:33:10 -0400
Austin S Hemmelgarn wrote:
> On 2014-04-04 04:02, Swâmi Petaramesh wrote:
> > - Is it still recommended to mkfs with a nodesize or leafsize
> > different (bigger) than the default ? I wouldn't like to lose too
> > much disk space anyway (1/2 nodesize per file on
George Mitchell posted on Sun, 06 Apr 2014 22:25:03 -0700 as excerpted:
> I am seeming to have an issue with a specific application. I just
> installed "Recoll", a really nice desktop search tool. And the
> following day whenever my backup program would attempt to run, my
> computer simply st
On 04/07/2014 05:42 AM, Duncan wrote:
George Mitchell posted on Sun, 06 Apr 2014 22:25:03 -0700 as excerpted:
I am seeming to have an issue with a specific application. I just
installed "Recoll", a really nice desktop search tool. And the
following day whenever my backup program would attempt
George Eleftheriou posted on Mon, 07 Apr 2014 12:34:27 +0200 as excerpted:
> Browsing the btrfs wiki for a relevant warning I just found this one:
>
> Caveat: Before Linux 3.9, which adds snapshot-aware defragmentation,
> defragmenting a file which had a COW copy (either a snapshot copy or one
>
On 2014-04-05 07:10, Swâmi Petaramesh wrote:
> Le samedi 5 avril 2014 10:12:17 Duncan wrote [excellent performance advice
> about disabling Akonadi in BTRFS etc]:
>
> Thanks Duncan for all this excellent discussion.
>
> However I'm still rather puzzled with a filesystem for which advice is "if
On 04/04/2014 11:20 AM, Filipe David Borba Manana wrote:
This new send flag makes send calculate first the amount of new file data (in
bytes)
the send root has relatively to the parent root, or for the case of a
non-incremental
send, the total amount of file data we will send through the send s
I added the ability to specify we needed the commit_sem for using the commit
root with send. However when we search clones we already hold the commit sem,
so we need to set path->need_commit_sem to 0 for this case. This patch also
makes it so we don't have to re-allocate a new path for every exte
Assuming thread 1 (may be VFS want to release the page) wants to
release a CLEAN page and thus the eb attaching the page.
and thread 2 wants to access the eb and cow the eb.
Thread 1
Thread 2
btree_releasepage
try_release_extent_buffer
release_extent_buffer
->if (atomic_dec_and_t
On 04/07/2014 11:45 AM, ylet ylet wrote:
Assuming thread 1 (may be VFS want to release the page) wants to
release a CLEAN page and thus the eb attaching the page.
and thread 2 wants to access the eb and cow the eb.
Thread 1
Thread 2
btree_releasepage
try_release_extent_buffer
hi Josef
Thanks, I got it. But i still have no idea to reliably reproduce it.
This bug-on is triggered when I ran POSTMARK test lasting two days.
BTW, can you reproduce the bug reported by email with title of "btrfs
hung with iozone test under linux kernel 3.14." The reported bug can
be reliably
On 04/07/2014 12:01 PM, ylet ylet wrote:
hi Josef
Thanks, I got it. But i still have no idea to reliably reproduce it.
This bug-on is triggered when I ran POSTMARK test lasting two days.
BTW, can you reproduce the bug reported by email with title of "btrfs
hung with iozone test under linux kern
I was debugging my why backup failed to run, and eventually found it was
stuck on sync:
14080 18:18 btrfs_tree_read_lock sync
This was hung for hours on this lock.
Strangely, it looks like taking my sysrq-w hung the machine pretty hard for
close to 30sec, but this seems to have un
On 04/07/2014 12:05 PM, Marc MERLIN wrote:
I was debugging my why backup failed to run, and eventually found it was
stuck on sync:
14080 18:18 btrfs_tree_read_lock sync
This was hung for hours on this lock.
Strangely, it looks like taking my sysrq-w hung the machine pretty hard
==This is the IOzone test bug (can be reliably
reproduced)==
Btrfs falls into hang when I ran iozone test with the following configuration:
./iozone -s 8g -i 0 -i 2 -i 1 -t 4 -r 4k -+w 50 -+y 20 -+C 60 -F
/mnt/btrfs/test1 /mnt/btrfs/test2 /mnt/b
On 04/07/2014 12:12 PM, ylet ylet wrote:
==This is the IOzone test bug (can be reliably
reproduced)==
Btrfs falls into hang when I ran iozone test with the following configuration:
./iozone -s 8g -i 0 -i 2 -i 1 -t 4 -r 4k -+w 50 -+y 20 -+C 60
On Fri, Apr 04, 2014 at 05:15:23PM -0400, Sasha Levin wrote:
> On 03/26/2014 01:01 PM, Jeff Mahoney wrote:
> > On 3/17/14, 9:05 AM, David Sterba wrote:
> >>> On Fri, Mar 14, 2014 at 08:12:16PM -0400, Sasha Levin wrote:
> > While fuzzing with trinity inside a KVM tools guest running the latest
On 04/07/2014 12:54 PM, David Sterba wrote:
On Fri, Apr 04, 2014 at 05:15:23PM -0400, Sasha Levin wrote:
On 03/26/2014 01:01 PM, Jeff Mahoney wrote:
On 3/17/14, 9:05 AM, David Sterba wrote:
On Fri, Mar 14, 2014 at 08:12:16PM -0400, Sasha Levin wrote:
While fuzzing with trinity inside a KVM
Thank you too for the enlightenment. Not just now but so many times in
the past (just the compilation of your list interventions is a wiki in
its own right).
Me too, I've been meaning to create a wiki account for quite some time
(but I was partly intimidated by the formality of the request :-)
)..
On 04/07/2014 01:17 PM, Chris Mason wrote:
>
>
> On 04/07/2014 12:54 PM, David Sterba wrote:
>> On Fri, Apr 04, 2014 at 05:15:23PM -0400, Sasha Levin wrote:
>>> On 03/26/2014 01:01 PM, Jeff Mahoney wrote:
On 3/17/14, 9:05 AM, David Sterba wrote:
>> On Fri, Mar 14, 2014 at 08:12:16PM -040
I was on vacation last week, I'll update btrfs-next today once we are happy
with integration. Thanks,
Josef
Sasha Levin wrote:
On 04/07/2014 01:17 PM, Chris Mason wrote:
>
>
> On 04/07/2014 12:54 PM, David Sterba wrote:
>> On Fri, Apr 04, 2014 at 05:15:23PM -0400, Sasha Levin wrote:
>>> On 0
On Mon, Apr 07, 2014 at 12:10:52PM -0400, Josef Bacik wrote:
> On 04/07/2014 12:05 PM, Marc MERLIN wrote:
> >I was debugging my why backup failed to run, and eventually found it was
> >stuck on sync:
> >14080 18:18 btrfs_tree_read_lock sync
> >
> >This was hung for hours on this loc
On 04/07/2014 02:03 PM, Sasha Levin wrote:
On 04/07/2014 01:17 PM, Chris Mason wrote:
On 04/07/2014 12:54 PM, David Sterba wrote:
On Fri, Apr 04, 2014 at 05:15:23PM -0400, Sasha Levin wrote:
On 03/26/2014 01:01 PM, Jeff Mahoney wrote:
On 3/17/14, 9:05 AM, David Sterba wrote:
On Fri, Mar 14
On 04/07/2014 02:51 PM, Marc MERLIN wrote:
On Mon, Apr 07, 2014 at 12:10:52PM -0400, Josef Bacik wrote:
On 04/07/2014 12:05 PM, Marc MERLIN wrote:
I was debugging my why backup failed to run, and eventually found it was
stuck on sync:
14080 18:18 btrfs_tree_read_lock sync
Thi
On Mon, Apr 07, 2014 at 03:32:13PM -0400, Chris Mason wrote:
> >You're recommending that I try btrfs-next on a 3.15 pre kernel, correct?
> >If so would it be likely to fix my filesystem and let me go back to a
> >stable 3.14? (I'm a bit warry about running some unstable 3.15 on it :).
>
> Right no
Hello
my HD recently started crashing, so I rescued all files to a new one and
thought that this might be a good time to convert from ext4 to btrfs. I
copied all the files from my old HD using dd, converted and then resized
the file system. However, my old drive already had some errors.
Currently
On Fri, Apr 04, 2014 at 02:07:16PM +0100, Filipe David Manana wrote:
> On Fri, Apr 4, 2014 at 10:03 AM, Dave Chinner wrote:
> > Hi folks,
> >
> > The xfstests repository at git://oss.sgi.com/xfs/cmds/xfstests has
> > just been updated. Patches often get missed, so please check if your
> > outstand
于 2014年04月05日 04:29, Marc MERLIN 写道:
On Wed, Apr 02, 2014 at 04:29:25PM +0800, Qu Wenruo wrote:
+If the source device is not available anymore, or if the -r option is set,
+the data is built only using the RAID redundancy mechanisms.
+After completion of the operation, the source device is remo
于 2014年04月07日 15:55, Sergei Trofimovich 写道:
From: Sergei Trofimovich
Reproducer:
mount /dev/ubda /mnt
mount -oremount,thread_pool=42 /mnt
Gives a crash:
? btrfs_workqueue_set_max+0x0/0x70
btrfs_resize_thread_pool+0xe3/0xf0
? sync_filesystem+0x0/0xc0
? btrfs_resiz
于 2014年04月05日 02:46, Marc MERLIN 写道:
On Wed, Apr 02, 2014 at 04:29:35PM +0800, Qu Wenruo wrote:
Convert man page for btrfs-zero-log
Signed-off-by: Qu Wenruo
---
Documentation/Makefile | 2 +-
Documentation/btrfs-zero-log.txt | 39 +++
2 files
35 matches
Mail list logo
