On 08/26/2014 10:51 AM, Eric Sandeen wrote:
> On 8/26/14, 5:55 AM, David Sterba wrote:
>> On Thu, Aug 21, 2014 at 08:08:57PM +0200, Goffredo Baroncelli wrote:
>>> Of course I (we) don't care cdrom and/or floppy, but this raises
>>> the question: are there other block devices which aren't showed in
Hi everyone,
I've just tagged btrfs-progs v3.16. Like the last few releases, this
one was prepared by Dave Sterba, who has been wrangling btrfs-progs
patches for some time now.
Dave has asked to officially take over the btrfs-progs maintenance, and
I said yes before he could change his mind. Ev
On 08/26/2014 06:20 AM, Martin Steigerwald wrote:
> Am Montag, 25. August 2014, 10:58:13 schrieb Chris Mason:
>> On 08/15/2014 11:36 AM, Liu Bo wrote:
>>> This has been reported and discussed for a long time, and this hang occurs
>>> in both 3.15 and 3.16.
>>
>
On 08/15/2014 11:36 AM, Liu Bo wrote:
> This has been reported and discussed for a long time, and this hang occurs in
> both 3.15 and 3.16.
[ great description ]
I ran this through tests last week, and an overnight test over the
weekend. It's in my for-linus branch now, along with everything els
On 08/20/2014 11:03 AM, David Sterba wrote:
> The commit "btrfs: disable strict file flushes for renames and
> truncates" (8d875f95da43c6a8f18f77869f2ef26e9594fecc) left some unused
> code and defines.
See my followup for the perf regression, we still need these. I was
never able to trigger the e
We should only be flushing on close if the file was flagged as needing
it during truncate. I broke this with my ordered data vs transaction
commit deadlock fix.
Thanks to Miao Xie for catching this.
Signed-off-by: Chris Mason
Reported-by: Miao Xie
Reported-by: Fengguang Wu
diff --git a/fs
On 08/20/2014 06:52 AM, Miao Xie wrote:
> On Tue, 19 Aug 2014 10:58:09 -0400, Chris Mason wrote:
>> On 08/19/2014 10:23 AM, David Sterba wrote:
>>> On Tue, Aug 19, 2014 at 07:58:20PM +0800, Fengguang Wu wrote:
>>>> We noticed
On 08/19/2014 11:33 AM, Liu Bo wrote:
> The crash is
>
> [ cut here ]
> kernel BUG at fs/btrfs/extent_io.c:2124!
> [...]
> Workqueue: btrfs-endio normal_work_helper [btrfs]
> RIP: 0010:[] []
> end_bio_extent_readpage+0xb45/0xcd0 [btrfs]
>
> This is in fact a regression
On 08/06/2014 10:51 PM, Qu Wenruo wrote:
> It seems that the patch is rejected in patchwork,
>
> Could any one tell me the reason?
I had nack'd it because I was worried at the time about the super crc
errors that Dave had found in the past. Sorry, I really thought I had
sent email about it.
But
On 08/19/2014 11:32 AM, Liu Bo wrote:
> We've defined a 'offset' out of bio_for_each_segment_all.
This isn't causing problems though? It should just be shadowing the
bio_for_each_segment_all variable for the duration of the curlies.
No objection as a cleanup, just making sure I'm not missing som
On 08/18/2014 05:42 PM, Mark Fasheh wrote:
> On Sun, Aug 17, 2014 at 03:09:21PM -0500, Eric Sandeen wrote:
>> Coverity pointed this out; in the newly added
>> qgroup_subtree_accounting(), if btrfs_find_all_roots()
>> returns an error, we leak at least the parents pointer,
>> and possibly the root
On 08/19/2014 10:23 AM, David Sterba wrote:
> On Tue, Aug 19, 2014 at 07:58:20PM +0800, Fengguang Wu wrote:
>> We noticed an xfstests failure on commit
>>
>> 8d875f95da43c6a8f18f77869f2ef26e9594fecc ("btrfs: disable strict file
>> flushes for renames and truncates")
>>
>> It's 100% reproducible in
On 08/16/2014 11:11 AM, Linus Torvalds wrote:
> On Fri, Aug 15, 2014 at 11:26 AM, Chris Mason wrote:
>>
>> I've been running xfstests with these against your current git
>> overnight, but I'm queueing up longer tests as well. I understand
>> you may want t
for the rest of the rcs.
These are all in my for-linus2 branch:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus2
Chris Mason (1) commits (+6/-267):
btrfs: disable strict file flushes for renames and truncates
David Sterba (1) commits (+45/-6):
btrfs:
On 08/15/2014 11:36 AM, Liu Bo wrote:
[ snip ]
>
> Besides, there're other cases that can lead to deadlock, but the real problem
> is that all btrfs workqueue shares one work->func, -- normal_work_helper,
> so this makes each workqueue to have its own helper function, but only a
> wraper pf norma
On 08/14/2014 06:28 PM, Marc MERLIN wrote:
> On Thu, Aug 14, 2014 at 06:03:09PM -0400, Chris Mason wrote:
>> At least I'll get to buy you a beer this time.
>
> Haha, no worries :)
>
>> Lets just see if the log root is the only problem. This will get you
>>
On 08/14/2014 01:27 PM, Marc MERLIN wrote:
> On Thu, Aug 14, 2014 at 12:52:35PM -0400, Austin S Hemmelgarn wrote:
>> I don't think it is likely that the Samsung SSD is to blame, in my
>> experience Samsung's SSD's are better than almost every other brand
>> except Intel, and I know that they hono
On 08/14/2014 02:10 PM, Linus Torvalds wrote:
> On Thu, Aug 14, 2014 at 11:59 AM, Chris Mason wrote:
>> Hi Linus,
>>
>> Please pull my for-linus branch:
>
> Yeah, I think this will be for the next merge window.
>
> This clearly got rebased today. At the end of
: use IS_ALIGNED() for assertion in btrfs_lookup_csums_range() for
simplicity (+2/-2)
btrfs: label should not contain return char (+12/-3)
chandan (1) commits (+1/-2):
Btrfs: fill_holes: Fix slot number passed to hole_mergeable() call.
HIMANGI SARAOGI (1) commits (+2/-2):
Btrfs: use BUG_ON
Chris Mas
Hi everyone,
I've pushed out a rebased integration tree with our patches so far. I'm
starting more tests now against Linus and linux-next.
-chris
--
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
On 08/12/2014 03:01 PM, Mark Fasheh wrote:
> On Tue, Aug 12, 2014 at 02:36:17PM -0400, Chris Mason wrote:
>>
>>
>> On 08/12/2014 02:32 PM, Mark Fasheh wrote:
>>> On Tue, Aug 12, 2014 at 02:22:31PM -0400, Chris Mason wrote:
>>>>
>>>>
>>&g
On 07/17/2014 03:39 PM, Mark Fasheh wrote:
> During its tree walk, btrfs_drop_snapshot() will skip any shared
> subtrees it encounters. This is incorrect when we have qgroups
> turned on as those subtrees need to have their contents
> accounted. In particular, the case we're concerned with is whe
On 08/12/2014 02:32 PM, Mark Fasheh wrote:
> On Tue, Aug 12, 2014 at 02:22:31PM -0400, Chris Mason wrote:
>>
>>
>> On 07/17/2014 03:39 PM, Mark Fasheh wrote:
>>> During its tree walk, btrfs_drop_snapshot() will skip any shared
>>> subtrees it encounters.
On 08/06/2014 11:14 AM, Takashi Iwai wrote:
>>>
>>> I meant that I don't care how you do it, if you want to do it the simple way
>>> first and then send the cleanup later thats fine by me. Thanks,
>>
>> Ah, misunderstood. Then please disregard my v2 patches and take just
>> v1 patch. It's even
On 08/12/2014 03:44 AM, Liu Bo wrote:
> This has been reported and discussed for a long time, and this hang occurs in
> both 3.15 and 3.16.
>
> Btrfs now migrates to use kernel workqueue, but it introduces this hang
> problem.
>
> Btrfs has a kind of work queued as an ordered way, which means
On 08/10/2014 10:55 AM, Liu Bo wrote:
> On Thu, Aug 07, 2014 at 10:02:15AM -0400, Chris Mason wrote:
>>
>>
>> On 08/07/2014 04:20 AM, Miao Xie wrote:
>>> On Thu, 7 Aug 2014 15:50:30 +0800, Liu Bo wrote:
>>>>>> [90496.156016] kworker/u8:14 D 88
On 08/09/2014 04:22 PM, Filipe Manana wrote:
> Under rare circumstances we can end up leaving 2 versions of a checksum
> for the same file extent range.
>
> The reason for this is that after calling btrfs_next_leaf we process
> slot 0 of the leaf it returns, instead of processing the slot set in
On 08/07/2014 04:20 AM, Miao Xie wrote:
> On Thu, 7 Aug 2014 15:50:30 +0800, Liu Bo wrote:
[90496.156016] kworker/u8:14 D 880044e38540 0 21050 2
0x
[90496.157683] Workqueue: btrfs-delalloc normal_work_helper [btrfs]
[90496.159320] 88022880f990
On 08/06/2014 11:18 AM, Chris Mason wrote:
> On 08/06/2014 10:43 AM, Martin Steigerwald wrote:
>> Am Mittwoch, 6. August 2014, 09:35:51 schrieb Chris Mason:
>>> On 08/06/2014 06:21 AM, Martin Steigerwald wrote:
>>>>> I think this should go to stable. Thanks, Li
On 08/06/2014 10:43 AM, Martin Steigerwald wrote:
> Am Mittwoch, 6. August 2014, 09:35:51 schrieb Chris Mason:
>> On 08/06/2014 06:21 AM, Martin Steigerwald wrote:
>>>> I think this should go to stable. Thanks, Liu.
>>
>> I'm definitely tagging this for stab
On 08/06/2014 06:21 AM, Martin Steigerwald wrote:
>> I think this should go to stable. Thanks, Liu.
I'm definitely tagging this for stable.
>
> Unfortunately this fix does not seem to fix all lockups.
The traces below are a little different, could you please send the whole
file?
-chris
>
>
On 08/01/2014 05:05 AM, Anand Jain wrote:
>
>
> Hi Chris,
>
> Looks like you missed Miao update (on 17 Jul) to back out the bad
> patch (below), and your integration branch (published on 25 Jul)
> still contains the same.
>
> [PATCH 2/2] Btrfs: fix wrong total device counter after removing a
On 07/29/2014 11:54 PM, Nick Krause wrote:
> Hey Guys ,
> I am new to reading and writing kernel code.I got interested in
> writing code for btrfs as it seems to
> need more work then other file systems and this seems other then
> drivers, a good use of time on my part.
> I interested in helpin
On 07/24/2014 10:16 PM, Qu Wenruo wrote:
> Hi chris,
>
> It seems that two of my wrong patches got merged in integration branch:
> 6068d17c8ab5bce946e9678ed2064e9f966cbe62 btrfs: Merge default subvolume
> mount codes into btrfs_mount_subvol().
> 8a2166332e332541f13b34b7248c0f14f575731e btrfs: Call
Hi everyone,
I've pushed out my current integration branch. It does have a few of
Miao Xie's patches missing because there were some rejects. I think
this was just because some things got pulled in out of order, and I'll
get it fixed up.
Also missing is Mark's quota snapshot deletion fixes. Th
On 06/26/2014 11:53 PM, Qu Wenruo wrote:
> Current btrfs will only use the first superblock, making the backup
> superblocks only useful for 'btrfs rescue super' command.
>
> The old problem is that if we use backup superblocks when the first
> superblock is not valid, we will be able to mount a
On 06/25/2014 07:55 PM, Eric Sandeen wrote:
> First off: total RFC, don't merge this; it builds, but
> is totally untested.
>
> open_ctree() is almost 1000 lines long. I've started trying
> to refactor it, primarily into helper functions, and also
> simplifying (?) things a bit at the beginning b
On 07/24/2014 02:49 PM, Martin Steigerwald wrote:
> Am Donnerstag, 24. Juli 2014, 10:58:51 schrieb Chris Mason:
>> On 07/23/2014 06:47 PM, Martin Steigerwald wrote:
>>> Am Dienstag, 15. Juli 2014, 17:08:27 schrieb Martin Steigerwald:
>>>> Am Dienstag, 15. Juli 2014
On 07/23/2014 06:47 PM, Martin Steigerwald wrote:
> Am Dienstag, 15. Juli 2014, 17:08:27 schrieb Martin Steigerwald:
>> Am Dienstag, 15. Juli 2014, 09:21:40 schrieb Chris Mason:
>>> On 07/14/2014 05:58 PM, Martin Steigerwald wrote:
>>>> Am Montag, 14. Juli 2014
On 07/24/2014 10:48 AM, Liu Bo wrote:
> When failing to allocate space for the whole compressed extent, we'll
> fallback to uncompressed IO, but we've forgotten to redirty the pages
> which belong to this compressed extent, and these 'clean' pages will
> simply skip 'submit' part and go to endio di
On 07/22/2014 07:39 PM, Dave Chinner wrote:
> On Tue, Jul 15, 2014 at 01:39:11PM -0400, Chris Mason wrote:
>> On 07/15/2014 11:26 AM, Morten Stevens wrote:
>>> Hi,
>>>
>>> I see that btrfs is using kernel workqueues since linux 3.15. After
>>> some
On 07/22/2014 05:13 PM, Martin Steigerwald wrote:
> Am Dienstag, 22. Juli 2014, 10:53:03 schrieb Chris Mason:
>> On 07/19/2014 02:23 PM, Martin Steigerwald wrote:
>>>> Running 3.15.6 with this patch applied on top:
>>>> - still causes a hang with `rsync -hPaHAXx
On 07/22/2014 03:42 PM, Torbjørn wrote:
> On 07/22/2014 04:53 PM, Chris Mason wrote:
>>
>> On 07/19/2014 02:23 PM, Martin Steigerwald wrote:
>>
>>>> Running 3.15.6 with this patch applied on top:
>>>> - still causes a hang with `rsync -hPaHAXx --
On 07/19/2014 02:23 PM, Martin Steigerwald wrote:
>> Running 3.15.6 with this patch applied on top:
>> - still causes a hang with `rsync -hPaHAXx --del /mnt/home/nyx/ /home/nyx/`
>> - no extra error messages printed (`dmesg | grep racing`) compared to
>> without the patch
>
> I got same result
Hi Linus,
We have two more fixes in my for-linus branch:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
I was hoping to also include a fix for a btrfs deadlock with compression
enabled, but we're still nailing that one down.
Liu Bo (1) commits (+11/-0):
Btrfs
On 07/19/2014 01:59 PM, Martin Steigerwald wrote:
> Am Freitag, 18. Juli 2014, 09:36:06 schrieb Chris Mason:
>> On 07/18/2014 03:51 AM, Martin Steigerwald wrote:
>>> Am Dienstag, 15. Juli 2014, 09:21:40 schrieb Chris Mason:
>>>> On 07/14/2014 05:58 PM, Martin Stei
On 07/18/2014 03:51 AM, Martin Steigerwald wrote:
> Am Dienstag, 15. Juli 2014, 09:21:40 schrieb Chris Mason:
>> On 07/14/2014 05:58 PM, Martin Steigerwald wrote:
>>> Am Montag, 14. Juli 2014, 16:12:22 schrieb Chris Mason:
>>>> On 07/14/2014 11:10 AM, Martin Steigerw
[ deadlocks during rsync in 3.15 with compression enabled ]
Hi everyone,
I still haven't been able to reproduce this one here, but I'm going
through a series of tests with lzo compression foraced and every
operation forced to ordered. Hopefully it'll kick it out soon.
While I'm hammering away,
On 07/17/2014 04:08 AM, Liu Bo wrote:
> xfstests generic/127 detected this problem.
>
> With commit 7fc34a62ca4434a79c68e23e70ed26111b7a4cf8, now fsync will only
> flush
> data within the passed range. This is the cause of the above problem,
> -- btrfs's fsync has a stage called 'sync log' which
On 07/15/2014 11:26 AM, Morten Stevens wrote:
> Hi,
>
> I see that btrfs is using kernel workqueues since linux 3.15. After
> some tests I noticed performance regressions with fs_mark.
>
> mount options: rw,relatime,compress=lzo,space_cache
>
> fs_mark on Kernel 3.14.9:
>
> # fs_mark -d /mnt/
On 07/14/2014 05:58 PM, Martin Steigerwald wrote:
> Am Montag, 14. Juli 2014, 16:12:22 schrieb Chris Mason:
>> On 07/14/2014 11:10 AM, Martin Steigerwald wrote:
>>> Am Montag, 14. Juli 2014, 17:04:22 schrieben Sie:
>>>> Hi!
>>>>
>>>> Whi
On 07/14/2014 11:10 AM, Martin Steigerwald wrote:
> Am Montag, 14. Juli 2014, 17:04:22 schrieben Sie:
>> Hi!
>>
>> While with 3.16-rc3 and rc4 I didn´t have a BTRFS hang in several days of
>> usage, with 3-16-rc5 I had a hang again. Less than a hour since booting it.
>>
>> Since the hang bug I and
Hi Linus,
We've queued up a few fixes in my for-linus branch, please pull:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
Anand Jain (7) commits (+68/-10):
btrfs: fix null pointer dereference in btrfs_show_devname when name is null
(+2/-0)
btrfs: fix null
On 07/03/2014 07:09 AM, Miao Xie wrote:
> CC Anand Jain
>
> Sorry, please ignore this patch.
> Anand wrote the same patch several days ago, so this bug fix belongs to Anand
> though he NACKed his patch at that time.
It certainly looks right, but Anand had mentioned that he had a few
questions on
On 7/2/14, 3:59 AM, "Harald Hoyer" wrote:
>On 01.07.2014 18:36, Chris Mason wrote:
>> On 07/01/2014 11:32 AM, David Sterba wrote:
>>> (adding Harald to CC)
>>>
>>> On Tue, Jul 01, 2014 at 05:30:01PM +0800, Qu Wenruo wrote:
>>>> Th
On 07/02/2014 08:24 PM, Qu Wenruo wrote:
>
> Original Message
> Subject: Re: [PATCH v2] btrfs: fix nossd and ssd_spread mount option
> regression
> From: Eric Sandeen
> To: Qu Wenruo , linux-btrfs@vger.kernel.org
> Date: 2014年07月03日 00:12
>> On 7/1/14, 11:19 PM, Qu Wenruo wrote:
On 07/02/2014 09:58 AM, Chris Mason wrote:
> On 07/02/2014 08:27 AM, Cody P Schafer wrote:
>
>>> Will do. The rsync I'm running is processing a lot of chromium cache
>>> files when it hangs (just for a reference), and ends up triggering a
>>> bunch of delet
On 07/02/2014 08:27 AM, Cody P Schafer wrote:
>> Will do. The rsync I'm running is processing a lot of chromium cache
>> files when it hangs (just for a reference), and ends up triggering a
>> bunch of deletes as well.
>
> Still a problem with your v3.15.y (eb97581), here's the log with
> sysrq-t
On 06/30/2014 07:42 PM, Cody P Schafer wrote:
> On Mon, Jun 30, 2014 at 1:30 PM, Chris Mason wrote:
>> On 06/30/2014 02:11 PM, Chris Mason wrote:
>>> On 06/29/2014 04:02 PM, Cody P Schafer wrote:
>>>> On Fri, Jun 27, 2014 at 7:22 PM, Chris Samuel wrote:
>>
On 07/01/2014 11:32 AM, David Sterba wrote:
> (adding Harald to CC)
>
> On Tue, Jul 01, 2014 at 05:30:01PM +0800, Qu Wenruo wrote:
>> This reverts commit 0723a0473fb48a1c93b113a28665b64ce5faf35a.
>> This commit has the following problem:
>> 1) Break the ro mount rule.
>> When users mount the whole
gt; Author: Peter Zijlstra
> Date: Thu Feb 6 18:16:07 2014 +0100
>
> arch: Prepare for smp_mb__{before,after}_atomic()
>
> Since the smp_mb__{before,after}*() ops are fundamentally dependent on
> how an arch can implement atomics it doesn't make sense to have 3
&g
On 06/30/2014 02:11 PM, Chris Mason wrote:
> On 06/29/2014 04:02 PM, Cody P Schafer wrote:
>> On Fri, Jun 27, 2014 at 7:22 PM, Chris Samuel wrote:
>>> On Fri, 27 Jun 2014 05:20:41 PM Duncan wrote:
>>>
>>>> If I'm not
On 06/29/2014 04:02 PM, Cody P Schafer wrote:
> On Fri, Jun 27, 2014 at 7:22 PM, Chris Samuel wrote:
>> On Fri, 27 Jun 2014 05:20:41 PM Duncan wrote:
>>
>>> If I'm not mistaken the fix for the 3.16 series bug was:
>>>
>>> ea4ebde02e08558b020c4b61bb9a4c0fcf63028e
>>>
>>> Btrfs: fix deadlocks with t
On 06/29/2014 03:43 PM, Filipe David Borba Manana wrote:
> The transaction handle was being used after being freed.
>
> Cc: Chris Mason
> Signed-off-by: Filipe David Borba Manana
> ---
> fs/btrfs/ioctl.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
On 06/08/2014 10:48 PM, Filipe David Borba Manana wrote:
> When cloning into a file, we were correctly replacing the extent
> items in the target range and removing the extent maps. However
> we weren't replacing the extent maps with new ones that point to
> the new extents - as a consequence, an
Btrfs: make free space cache write out functions more readable (+93/-66)
Btrfs: fix broken free space cache after the system crashed (+186/-44)
Btrfs: fix deadlock when mounting a degraded fs (+9/-1)
Btrfs: use bio_endio_nodec instead of open code (+1/-8)
Chris Mason (1) commits (+4
On 06/20/2014 05:53 AM, David Sterba wrote:
> Hi Chris,
>
> any reason why the patches 1-5 were not added to 3.16 queue?
>
> On Tue, Jun 03, 2014 at 11:35:58AM +0800, Anand Jain wrote:
>> btrfs: rename add_device_membership to btrfs_kobj_add_device
>> btrfs: dev delete should remove sysfs e
On 06/20/2014 05:53 AM, David Sterba wrote:
> Hi Chris,
>
> any reason why the patches 1-5 were not added to 3.16 queue?
>
> On Tue, Jun 03, 2014 at 11:35:58AM +0800, Anand Jain wrote:
>> btrfs: rename add_device_membership to btrfs_kobj_add_device
>> btrfs: dev delete should remove sysfs e
On 06/19/2014 04:10 PM, Chris Mason wrote:
> On 06/19/2014 01:52 PM, Waiman Long wrote:
>> On 06/19/2014 12:51 PM, Chris Mason wrote:
>>> On 06/18/2014 11:21 PM, Waiman Long wrote:
>>>> On 06/18/2014 10:11 PM, Chris Mason wrote:
>>>>> On 06/18/2014 10
On 06/19/2014 01:52 PM, Waiman Long wrote:
> On 06/19/2014 12:51 PM, Chris Mason wrote:
>> On 06/18/2014 11:21 PM, Waiman Long wrote:
>>> On 06/18/2014 10:11 PM, Chris Mason wrote:
>>>> On 06/18/2014 10:03 PM, Marc Dionne wrote:
>>>>> On Wed, Jun 1
On 06/18/2014 11:21 PM, Waiman Long wrote:
> On 06/18/2014 10:11 PM, Chris Mason wrote:
>> On 06/18/2014 10:03 PM, Marc Dionne wrote:
>>> On Wed, Jun 18, 2014 at 8:41 PM, Marc
>>> Dionne wrote:
>>>> On Wed, Jun 18, 2014 at 8:08 PM, Waiman Long
>>
On 06/18/2014 10:03 PM, Marc Dionne wrote:
> On Wed, Jun 18, 2014 at 8:41 PM, Marc Dionne wrote:
>> On Wed, Jun 18, 2014 at 8:08 PM, Waiman Long wrote:
>>> On 06/18/2014 08:03 PM, Marc Dionne wrote:
>
> And for an additional data point, just removing those
> CONFIG_DEBUG_LOCK_ALLOC ifdefs looks
On 06/18/2014 07:30 PM, Waiman Long wrote:
> On 06/18/2014 07:27 PM, Chris Mason wrote:
>> On 06/18/2014 07:19 PM, Waiman Long wrote:
>>> On 06/18/2014 07:10 PM, Josef Bacik wrote:
>>>>
>>>> On 06/18/2014 03:47 PM, Waiman Long wrote:
>&
On 06/18/2014 07:19 PM, Waiman Long wrote:
> On 06/18/2014 07:10 PM, Josef Bacik wrote:
>>
>>
>> On 06/18/2014 03:47 PM, Waiman Long wrote:
>>> On 06/18/2014 06:27 PM, Josef Bacik wrote:
On 06/18/2014 03:17 PM, Waiman Long wrote:
> On 06/18/2014 04:57 PM, Marc Dionne wrote:
>
On 06/16/2014 11:06 PM, Tsutomu Itoh wrote:
> On 2014/06/17 11:10, Tsutomu Itoh wrote:
>> On 2014/06/17 9:47, Chris Mason wrote:
>>> On 06/16/2014 07:57 PM, Tsutomu Itoh wrote:
>>>> On 2014/06/17 8:52, Chris Mason wrote:
>>>>> On 06/16/2014
On 06/16/2014 07:57 PM, Tsutomu Itoh wrote:
> On 2014/06/17 8:52, Chris Mason wrote:
>> On 06/16/2014 07:28 PM, Tsutomu Itoh wrote:
>>> Hi Chris,
>>>
>>> On 2014/06/17 2:56, Chris Mason wrote:
>>>> On 06/16/2014 02:35 AM, Tsutomu Itoh wrote
On 06/16/2014 07:57 PM, Tsutomu Itoh wrote:
> On 2014/06/17 8:52, Chris Mason wrote:
>> On 06/16/2014 07:28 PM, Tsutomu Itoh wrote:
>>> Hi Chris,
>>>
>>> On 2014/06/17 2:56, Chris Mason wrote:
>>>> On 06/16/2014 02:35 AM, Tsutomu Itoh wrote:
>>
On 06/16/2014 07:28 PM, Tsutomu Itoh wrote:
> Hi Chris,
>
> On 2014/06/17 2:56, Chris Mason wrote:
>> On 06/16/2014 02:35 AM, Tsutomu Itoh wrote:
>>> I encountered soft lockup when executing 'xfstests btrfs/042' on 3.16-rc1.
>>>
>>
>> Did
On 06/16/2014 02:35 AM, Tsutomu Itoh wrote:
> I encountered soft lockup when executing 'xfstests btrfs/042' on 3.16-rc1.
>
Did we recover, or was it stuck forever?
-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.o
Hi Linus,
Please pull my for-linus branch:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
This has a few fixes since our last pull and a new ioctl for doing btree
searches from userland. It's very similar to the existing ioctl, but
lets us return larger items bac
On 06/13/2014 05:09 AM, Filipe David Manana wrote:
> On Tue, Jun 10, 2014 at 7:17 PM, Filipe David Borba Manana
> wrote:
>> When CONFIG_PROVE_RCU=y and CONFIG_PROVE_RCU_REPEATEDLY=y, the
>> following was dumped in dmesg:
>>
>> [ 3197.218064] ===
>> [ 3197.218064] [ INFO
On 06/11/2014 08:12 PM, Filipe David Borba Manana wrote:
> Often when running the qgroups sanity test, a crash or a hang happened.
> This is because the extent buffer the test uses for the root node doesn't
> have an header level explicitly set, making it have a random level value.
> This is a prob
o report errors to userspace (+2/-0)
Btrfs: fix NULL pointer crash of deleting a seed device (+8/-4)
Btrfs: fix leaf corruption after __btrfs_drop_extents (+18/-0)
Btrfs: do not increment on bio_index one by one (+1/-1)
Btrfs: use right type to get real comparison (+1/-1)
Chris Mason
On 06/10/2014 07:14 AM, Ed Tomlinson wrote:
> On Monday 09 June 2014 12:17:50 Sasha Levin wrote:
>> On 06/09/2014 11:59 AM, Chris Mason wrote:
>>> On 06/09/2014 11:16 AM, Sasha Levin wrote:
>>>>> Hi all,
>>>>>
>>>>> It seems t
On 06/09/2014 11:16 AM, Sasha Levin wrote:
> Hi all,
>
> It seems that some recent changes to btrfs tests make it hang during boot:
>
> [ 49.730033] NMI watchdog: BUG: soft lockup - CPU#34 stuck for 23s!
> [swapper/0:1]
> [ 49.730033] Modules linked in:
> [ 49.730033] hardirqs last enabled
On 06/09/2014 10:40 AM, Dan Carpenter wrote:
> Hello Chris Mason,
>
> The patch 263524b4ac6b: "Btrfs: split up __extent_writepage to lower
> stack usage" from May 21, 2014, leads to the following static checker
> warning:
>
> fs/btrfs/extent_io.
Hi Linus,
I had this in my 3.16 merge window queue, but it is small and obvious
enough for 3.15. I cherry-picked and retested against current rc8.
Please pull from my for-linus branch:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
Filipe Manana (1) commits (+5/
On 06/03/2014 11:53 AM, David Sterba wrote:
> On Sat, May 31, 2014 at 11:48:28PM +, Philip Worrall wrote:
>> LZ4 is a lossless data compression algorithm that is focused on
>> compression and decompression speed. LZ4 gives a slightly worse
>> compression ratio compared with LZO (and much worse
On 05/28/2014 01:53 AM, Torbjørn wrote:
> It's actually a raid10 array of 11 dm-crypt devices.
> I'm able to read data from the array (accessing files), and also read
> directly from all the underlying dm-crypt devices using dd, if that's
> what you meant.
>
> I have not rebooted the system since
On 05/27/2014 04:50 PM, Chris Mason wrote:
> On 05/27/2014 04:42 PM, Torbjørn wrote:
>> On 05/27/2014 10:08 PM, Torbjørn wrote:
>>> On 05/27/2014 09:09 PM, Chris Mason wrote:
>>>>
>>>> On 05/27/2014 02:11 PM, Torbjørn wrote:
>>>>> Hi,
>&g
On 05/27/2014 04:42 PM, Torbjørn wrote:
> On 05/27/2014 10:08 PM, Torbjørn wrote:
>> On 05/27/2014 09:09 PM, Chris Mason wrote:
>>>
>>> On 05/27/2014 02:11 PM, Torbjørn wrote:
>>>> Hi,
>>>>
>>>> Btrfs-transaction keeps blocking for
On 05/23/2014 07:13 PM, Marc MERLIN wrote:
> On Fri, May 23, 2014 at 04:24:49PM -0400, Chris Mason wrote:
>>> I was able to kill btrfs send and receive, but mencoder is very hung, and
>>> sync does not finish either:
>>> 10654 merlin syncs
On 05/27/2014 02:11 PM, Torbjørn wrote:
> Hi,
>
> Btrfs-transaction keeps blocking for me on all 3.15-rc versions.
> 3.14 does not have this issue.
> The process never gets unstuck. btrfs fi sync does not help. A hard
> reboot seems to be the only way to recover.
>
> The volume is still readabl
On 05/27/2014 01:20 PM, Jeff Mahoney wrote:
> - gpg control packet
> On 5/27/14, 1:22 PM, Chris Mason wrote:
>
>
>> On 05/27/2014 01:08 PM, Chris Mason wrote:
>>> On 05/27/2014 12:59 PM, Jeff Mahoney wrote:
>>>> We are currently allocating space_info ob
On 05/27/2014 01:08 PM, Chris Mason wrote:
> On 05/27/2014 12:59 PM, Jeff Mahoney wrote:
>> We are currently allocating space_info objects in an array when we
>> allocate space_info. When a user does something like:
>>
>> # btrfs balance start -mconvert=raid1 -dco
On 05/27/2014 12:59 PM, Jeff Mahoney wrote:
> We are currently allocating space_info objects in an array when we
> allocate space_info. When a user does something like:
>
> # btrfs balance start -mconvert=raid1 -dconvert=raid1 /mnt
> # btrfs balance start -mconvert=single -dconvert=single /mnt -f
On 05/26/2014 09:35 PM, Jeff Mahoney wrote:
> We are currently allocating space_info objects in an array when we
> allocate space_info. When a user does something like:
>
> # btrfs balance start -mconvert=raid1 -dconvert=raid1 /mnt
> # btrfs balance start -mconvert=single -dconvert=single /mnt -f
On 05/23/2014 10:17 AM, Marc MERLIN wrote:
> I had btrfs send/receive running.
>
> Plugging the power in caused laptop-mode to remount my root partition.
>
> That hung, and in turn all of btrfs hung too.
>
> 7668 root btrfs send home_ro.20140523 -
> 7669 root btrfs receive /mnt/btrfs_p
On 05/22/2014 11:05 AM, Jeff Mahoney wrote:
> - gpg control packet
> On 5/22/14, 8:19 AM, Chris Mason wrote:
>> Can we safely reinit a kobject that has been put in use in sysfs?
>> Given all the things that can hold refs etc is this legal?
>
> It depends on how the kobjec
On 05/21/2014 09:21 PM, Jeff Mahoney wrote:
> On 05/21/2014 08:12 PM, Chris Mason wrote:
>>
>> The Btrfs sysfs code removes entries for raid types that are no
>> longer in use. This means that if you have a raid0 FS and use balance
>> to turn it into a raid1 FS, the
601 - 700 of 2656 matches
Mail list logo
