Hello, Steven, Linus.
On Thu, Mar 24, 2011 at 09:38:58PM -0700, Linus Torvalds wrote:
> On Thu, Mar 24, 2011 at 8:39 PM, Steven Rostedt wrote:
> >
> > But now, mutex_trylock(B) becomes a spinner too, and since the B's owner
> > is running (spinning on A) it will spin as well waiting for A's owner
On Thu, Mar 24, 2011 at 8:39 PM, Steven Rostedt wrote:
>
> But now, mutex_trylock(B) becomes a spinner too, and since the B's owner
> is running (spinning on A) it will spin as well waiting for A's owner to
> release it. Unfortunately, A's owner is also spinning waiting for B to
> release it.
>
>
On Thu, Mar 24, 2011 at 10:41:51AM +0100, Tejun Heo wrote:
> Adaptive owner spinning used to be applied only to mutex_lock(). This
> patch applies it also to mutex_trylock().
>
> btrfs has developed custom locking to avoid excessive context switches
> in its btree implementation. Generally, doin
On Thu, Mar 24, 2011 at 09:18:16AM +0100, Ingo Molnar wrote:
>
> * Tejun Heo wrote:
>
> > NOT-Signed-off-by: Tejun Heo
>
> s/NOT-// ?
>
Perhaps because it is still in RFC context?
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to
On Fri, 25 Mar 2011 00:07:59 +0100, David Sterba wrote:
> On Thu, Mar 24, 2011 at 07:41:21PM +0800, Miao Xie wrote:
>> In the filesystem context, we must allocate memory by GFP_NOFS,
>> or we may start another filesystem operation and make kswap thread hang up.
>
> indeed. Did you check for other
Hi,
there's one thing I want to bring up. It's not related to delayed
functionality itself but to git tree base of the patch.
There's a merge conflict when your patch is applied directly onto
Linus' tree, and not when on Chris' one.
On Thu, Mar 24, 2011 at 07:41:31PM +0800, Miao Xie wrote:
...
>
Hi,
On Thu, Mar 24, 2011 at 07:41:21PM +0800, Miao Xie wrote:
> In the filesystem context, we must allocate memory by GFP_NOFS,
> or we may start another filesystem operation and make kswap thread hang up.
indeed. Did you check for other GFP_KERNEL allocations? I've found 8 more
them and at least
Hallo, Goffredo,
Du meintest am 24.03.11:
>> what about disks with more than 2 TByte? Other filesystems (?) need
>> GPT.
> The filesystems don't care about the partition system.
Ok - thank you!
Viele Gruesse!
Helmut
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
t
On 03/24/2011 05:43 PM, Helmut Hullen wrote:
> Hallo, linux-btrfs,
>
> what about disks with more than 2 TByte? Other filesystems (?) need GPT.
The filesystems don't care about the partition system. The 2TB limits is
related to the maximum partition size. Of course a filesystem cannot be
greater
extent_buffer implemented custom locking which required explicit
distinction between non-sleepable and sleepable lockings. This was to
prevent excessive context switches.
For short non-blocking acquisitions, lock was left non-blocking and
other threads which wanted to lock the same eb would spin
btrfs_set_buffer_lockdep_class() should be dependent upon
CONFIG_LOCKDEP instead of CONFIG_DEBUG_LOCK_ALLOC. Collect the
related code into one place, use CONFIG_LOCKDEP instead and make some
cosmetic changes.
Signed-off-by: Tejun Heo
---
fs/btrfs/disk-io.c | 22 ++
fs/btrf
Due to the custom extent_buffer locking implementation, currently
lockdep doesn't have visibility into btrfs locking when the locks are
switched to blocking, hiding most of lock ordering issues from
lockdep.
With planned switch to mutex, all extent_buffer locking operations
will be visible to lock
Hello,
This is split patchset of the RFC patches[1] to simplify btrfs
locking and contains the following three patches.
0001-btrfs-Cleanup-extent_buffer-lockdep-code.patch
0002-btrfs-Use-separate-lockdep-class-keys-for-different-.patch
0003-btrfs-Simplify-extent_buffer-locking.patch
For more
Hallo, linux-btrfs,
what about disks with more than 2 TByte? Other filesystems (?) need GPT.
When I use
mkfs.btrfs /dev/sdc
(p.e. with drive sdc), does that work without problems with btrfs?
Viele Gruesse!
Helmut
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
t
On Thu, Mar 24, 2011 at 11:25:29AM +0100, Arne Jansen wrote:
> Thanks, I'll add you as Reported-by if that's ok.
Ok it is :)
dave
--
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.ker
On 24.03.2011 13:58, Arne Jansen wrote:
> On 23.03.2011 18:28, David Sterba wrote:
>> Hi,
>>
>> you are adding a new smp_mb, can you please explain why it's needed and
>> document it?
>>
>> thanks,
>> dave
>>
>> On Fri, Mar 18, 2011 at 04:55:07PM +0100, Arne Jansen wrote:
>>> This adds several sync
On 23.03.2011 18:28, David Sterba wrote:
> Hi,
>
> you are adding a new smp_mb, can you please explain why it's needed and
> document it?
>
> thanks,
> dave
>
> On Fri, Mar 18, 2011 at 04:55:07PM +0100, Arne Jansen wrote:
>> This adds several synchronizations:
>> - for a transaction commit, the
On thu, 24 Mar 2011 08:29:57 +0100, Arne Jansen wrote:
> On 24.03.2011 02:38, Miao Xie wrote:
>> On wed, 23 Mar 2011 21:28:25 +0100, Arne Jansen wrote:
>>> On 23.03.2011 20:26, Andrey Kuzmin wrote:
On Wed, Mar 23, 2011 at 4:06 PM, Arne Jansen wrote:
> The main idea is to load the tre
In the filesystem context, we must allocate memory by GFP_NOFS,
or we may start another filesystem operation and make kswap thread hang up.
Signed-off-by: Miao Xie
---
fs/btrfs/extent-tree.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/b
Tracepoints can provide insight into why btrfs hits bugs and be greatly
helpful for debugging, e.g
dd-7822 [000] 2121.641088: btrfs_inode_request: root =
5(FS_TREE), gen = 4, ino = 256, blocks = 8, disk_i_size = 0, last_trans = 8,
logged_trans = 0
dd-7822 [000] 21
Make the function public as we should update the reserved extents calculations
after taking out an extent for trimming.
Signed-off-by: Li Dongyang
---
fs/btrfs/ctree.h|2 ++
fs/btrfs/extent-tree.c | 16 +++-
2 files changed, 9 insertions(+), 9 deletions(-)
create mode
Dear list,
This is V4 of batched discard support, now we will get full mapping of
the free space on each device for RAID0/1/10/DUP instead of just a single
stripe length, and tested with xfsstests 251, Thanks.
Changelog V4:
*make btrfs_map_block() return full mapping.
Changelog V3:
*fix sty
Callers of btrfs_discard_extent() should check if we are mounted with -o
discard,
as we want to make fitrim to work even the fs is not mounted with -o discard.
Also we should use REQ_DISCARD to map the free extent to get a full mapping,
last we only return errors if
1. the error is not a EOPNOTSUP
btrfs_map_block() will only return a single stripe length, but we want the
full extent be mapped to each disk when we are trimming the extent,
so we add length to btrfs_bio_stripe and fill it if we are mapping for
REQ_DISCARD.
Signed-off-by: Li Dongyang
---
fs/btrfs/volumes.c | 150 +++
We take an free extent out from allocator, trim it, then put it back,
but before we trim the block group, we should make sure the block group is
cached, so plus a little change to make cache_block_group() run without a
transaction.
Signed-off-by: Li Dongyang
---
fs/btrfs/ctree.h|
On 23.03.2011 18:18, David Sterba wrote:
> Hi,
>
> I'm reviewing the atomic counters and the wait/wake infrastructure,
> just found two missed mutex_unlock()s in btrfs_scrub_dev() in error
> paths.
>
> On Fri, Mar 18, 2011 at 04:55:06PM +0100, Arne Jansen wrote:
>> This is the main scrub code.
>
I had a system freeze for some reason with 2.6.38.
I made a hard reboot, just to discover some of the files (KVM images, were in
use when the crash happened) on btrfs RAID-1 filesystem are corrupted:
btrfs csum failed ino 257 off 120180736 csum 4246715593 private 48329
btrfs csum failed ino 257
While doing a filesystem balance, lockdep detecting a potential lock
ordering issue [1].
Thanks,
Daniel
--- [1]
===
[ INFO: possible circular locking dependency detected ]
2.6.38.1-341cd+ #10
--
Ugh... Please drop the extra "Subject: " from subject before applying.
Thanks.
--
tejun
--
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
Adaptive owner spinning used to be applied only to mutex_lock(). This
patch applies it also to mutex_trylock().
btrfs has developed custom locking to avoid excessive context switches
in its btree implementation. Generally, doing away with the custom
implementation and just using the mutex shows
Separate out mutex_spin() out of __mutex_lock_common(). The fat
comment is converted to docbook function description.
While at it, drop the part of comment which explains that adaptive
spinning considers whether there are pending waiters, which doesn't
match the code.
This patch is to prepare fo
> IMHO, this is related to how the debug options of the kernel are
> configured. Attached you find two config files, both for kernel
> version 2.6.38, with the one named 2.6.38-debug everything works and
> with the other one newly created subvolumes are read only.
>
I've figured out what's wrong.
I found that I'm able to provoke undefined behaviour with 2.6.38 with
extent defragmenting + recompression, eg:
mkfs.btrfs /dev/sdb
mount /dev/sdb /mnt
cp -xa / /mnt
find /mnt -print0 | xargs -0 btrfs filesystem defragment -vc
After a short time, I was seeing what looked like a secondary effect
[
* Tejun Heo wrote:
> NOT-Signed-off-by: Tejun Heo
s/NOT-// ?
Ingo
--
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
On 24.03.2011 02:38, Miao Xie wrote:
> On wed, 23 Mar 2011 21:28:25 +0100, Arne Jansen wrote:
>> On 23.03.2011 20:26, Andrey Kuzmin wrote:
>>> On Wed, Mar 23, 2011 at 4:06 PM, Arne Jansen wrote:
The main idea is to load the tree (or parts of it) top-down, order the
needed blocks and dist
35 matches
Mail list logo