When I am creating subvolumes I get this strange behavior. If
I create a subvolume with a name longer than 4 characters it
is read-only, if the name is shorter than 5 characters the
subvolume is writeable as expected. I think it is since I
upgraded to kernel version 2.6.38 (I do not create
This patch is checking return value of read_tree_block(),
and if it is NULL, error processing.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/ctree.c |3 +++
fs/btrfs/extent-tree.c |6 ++
fs/btrfs/relocation.c |6 ++
3 files changed, 15 insertions(+)
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 Jansensensi...@gmx.net wrote:
The main idea is to load the tree (or parts of it) top-down, order the
needed blocks and
* Tejun Heo t...@kernel.org wrote:
NOT-Signed-off-by: Tejun Heo t...@kernel.org
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
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
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.
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
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
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
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
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
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.
+
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 lidongy...@novell.com
---
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 lidongy...@novell.com
---
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
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
Make the function public as we should update the reserved extents calculations
after taking out an extent for trimming.
Signed-off-by: Li Dongyang lidongy...@novell.com
---
fs/btrfs/ctree.h|2 ++
fs/btrfs/extent-tree.c | 16 +++-
2 files changed, 9 insertions(+), 9
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]
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 mi...@cn.fujitsu.com
---
fs/btrfs/extent-tree.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git
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 Jansensensi...@gmx.net wrote:
The main idea is to load the
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 scrub gets
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 synchronizations:
- for
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
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
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
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
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 t...@kernel.org
---
fs/btrfs/disk-io.c | 22
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
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
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
the
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
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:
...
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
On Thu, Mar 24, 2011 at 09:18:16AM +0100, Ingo Molnar wrote:
* Tejun Heo t...@kernel.org wrote:
NOT-Signed-off-by: Tejun Heo t...@kernel.org
s/NOT-// ?
Perhaps because it is still in RFC context?
-- Steve
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the
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, doing
On Thu, Mar 24, 2011 at 8:39 PM, Steven Rostedt rost...@goodmis.org 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
36 matches
Mail list logo
