Hi-
I'm pretty reliably triggering the following bug after powercycling an
active btrfs + ceph workload and then trying to remount. Is this a known
issue?
sage
2013-06-04T18:54:28.532988-07:00 plana71 kernel: [ 39.311120] [
cut here ]
On Wed, 5 Jun 2013, Josef Bacik wrote:
On Tue, Jun 04, 2013 at 09:59:05PM -0600, Sage Weil wrote:
Hi-
I'm pretty reliably triggering the following bug after powercycling an
active btrfs + ceph workload and then trying to remount. Is this a known
issue?
Yeah sorry it's fixed
I'm also seeing this hang regularly with both 3.9 and 3.10-rc5. Is this
is a known problem? In this case there is no powercycling; just a regular
ceph-osd workload.
Thanks-
sage
[ 2885.479116] INFO: task kworker/u64:1:28713 blocked for more than 120 seconds.
[ 2885.486277] echo 0
On Wed, 12 Jun 2013, Sage Weil wrote:
On Tue, 11 Jun 2013, Chris Mason wrote:
Quoting Sage Weil (2013-06-11 11:43:30)
I'm also seeing this hang regularly with both 3.9 and 3.10-rc5. Is this
is a known problem? In this case there is no powercycling; just a regular
ceph-osd workload
Hi Chris,
On Tue, 18 Jun 2013, Chris Mason wrote:
[...]
Very long way of saying I think we're one release_path short. Sage, I
haven't tested this at all yet, I was hoping to trigger it first.
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index c276ac9..c1954b3 100644
---
On Wed, 19 Jun 2013, Sage Weil wrote:
Hi Chris,
On Tue, 18 Jun 2013, Chris Mason wrote:
[...]
Very long way of saying I think we're one release_path short. Sage, I
haven't tested this at all yet, I was hoping to trigger it first.
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree
On Thu, 20 Jun 2013, Chris Mason wrote:
Quoting Sage Weil (2013-06-20 17:56:19)
On Wed, 19 Jun 2013, Sage Weil wrote:
Hi Chris,
On Tue, 18 Jun 2013, Chris Mason wrote:
[...]
Very long way of saying I think we're one release_path short. Sage, I
haven't tested this at all
On Thu, 20 Jun 2013, Chris Mason wrote:
Quoting Sage Weil (2013-06-20 21:00:21)
On Thu, 20 Jun 2013, Chris Mason wrote:
Awesome, thanks for getting the traces for us. Looks like this one has
been around since v3.7, so I'm not going to try and sneak it into the
3.10 final. I'll have
Hi Chris,
On Thu, 20 Jun 2013, Chris Mason wrote:
Quoting Sage Weil (2013-06-20 17:56:19)
On Wed, 19 Jun 2013, Sage Weil wrote:
Hi Chris,
On Tue, 18 Jun 2013, Chris Mason wrote:
[...]
Very long way of saying I think we're one release_path short. Sage, I
haven't tested
On Fri, 25 Apr 2008, Chris Mason wrote:
Very cool. I'd actually loved to see this wrapped into a program that will
cow a directory tree. Basically the same as cp -al, but with cow instead of
linking.
Yeah definitely. I added a -c/--cow flag to GNU cp, but am having trouble
coercing
no
way to tell if the application considers a given operation as part of it's
transaction.
I'm not sure if throttle_on_drops() should also be avoided in that case?
Obviously, if the transaction start/stop ioctls aren't being used, there
is no effect on current behavior.
Signed-off-by: Sage
Hi,
This patch adds an additional CLONE_RANGE ioctl to clone an arbitrary
(block-aligned) file range to another file. The original CLONE ioctl
becomes a special case of cloning the entire file range. The logic is a
bit more complex now since ranges may be cloned to different offsets, and
On Fri, 14 Nov 2008, Chris Mason wrote:
On Thu, 2008-10-30 at 12:32 -0700, Sage Weil wrote:
Hi,
This patch adds an additional CLONE_RANGE ioctl to clone an arbitrary
(block-aligned) file range to another file. The original CLONE ioctl
becomes a special case of cloning the entire
Remove unneeded debugging sanity check. It gets corrupted anyway when
multiple btrfs file systems are mounted, throwing bad warnings along the
way.
Signed-off-by: Sage Weil [EMAIL PROTECTED]
---
fs/btrfs/transaction.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git
BTW it looks like the commit log made it into git, but not the patch
itself... :)
sage
On Fri, 12 Dec 2008, Yehuda Sadeh Weinraub wrote:
Fix bug, btrfs_listxattr doesn't return an error when the buffer size
is too small (ret was overridden).
Signed-off-by: Yehuda Sadeh
On Fri, 19 Dec 2008, Yan Zheng wrote:
I noticed some data and metadata getting out of sync on disk, despite
wrapping my writes with btrfs transactions. After digging into it a bit,
it appears to be a larger problem with inode size/data getting written
during a regular commit.
[...]
Add a 'notreelog' mount option to disable the tree log (used by fsync,
O_SYNC writes).
Signed-off-by: Sage Weil s...@newdream.net
---
fs/btrfs/ctree.h|1 +
fs/btrfs/super.c|8 +++-
fs/btrfs/tree-log.c |4
3 files changed, 12 insertions(+), 1 deletions(-)
diff --git
in commit_transaction, or is not
needed by sync_fs either...?
Let me know if this looks reasonable, or if you would prefer a different
approach.
Thanks-
Signed-off-by: Sage Weil s...@newdream.net
---
fs/btrfs/ctree.h |1 +
fs/btrfs/disk-io.c |6 +++---
fs/btrfs/extent-tree.c |6
they are bound to (by
BTRFS_IOC_TRANS_{START,END}).
Signed-off-by: Sage Weil s...@newdream.net
---
fs/btrfs/ctree.h |1 +
fs/btrfs/super.c | 10 +++---
fs/btrfs/transaction.c |5 -
3 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
...and this one!
thanks-
sage
On Fri, 23 Jan 2009, Sage Weil wrote:
Hi Chris-
Here's a simpler version of the patch that drops the unrelated sync_fs
stuff.
thanks-
sage
The 'flushoncommit' mount option forces any data dirtied by a write in a
prior transaction to commit as part
Hi Chris-
Just pinging you on this patch...
On Fri, 23 Jan 2009, Sage Weil wrote:
Add a 'notreelog' mount option to disable the tree log (used by fsync,
O_SYNC writes).
Signed-off-by: Sage Weil s...@newdream.net
---
fs/btrfs/ctree.h|1 +
fs/btrfs/super.c|8 +++-
fs
in
btrfs_start_ioctl_transaction().
Signed-off-by: Sage Weil s...@newdream.net
---
fs/btrfs/transaction.c | 40
1 files changed, 32 insertions(+), 8 deletions(-)
diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
index 2869b33..4a8d4f0 100644
--- a/fs/btrfs
On Thu, 23 Apr 2009, Chris Mason wrote:
On Mon, 2009-04-13 at 09:40 -0700, Sage Weil wrote:
Starting in b7ec40d7845bffca8bb3af2ea3f192d6257bbe21, drop_dirty_roots()
tries to avoid generating delayed refs in a transaction that is currently
closing (and trying to flush dirty refs out
, wait on all ordered extents. Otherwise,
only pass the nocow_only flag to wait_ordered_extents if snap_pending.
Signed-off-by: Sage Weil s...@newdream.net
---
fs/btrfs/transaction.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/transaction.c b/fs/btrfs
indefinitely. But on locked down
hosts (i.e. no users), that can be inconvenient because daemons using
transactions have to run as root.
Signed-off-by: Sage Weil s...@newdream.net
---
fs/btrfs/ctree.h |1 +
fs/btrfs/ioctl.c |3 ++-
fs/btrfs/super.c |9 -
3 files changed, 11
On Fri, 26 Jun 2009, Christoph Hellwig wrote:
On Thu, Jun 25, 2009 at 02:45:39PM -0700, Sage Weil wrote:
This lets an administrator give non-root users access to the btrfs
transaction start/end ioctls via a mount option.
Currently any process using the ioctls must run as root. That's
On Mon, 24 Aug 2009, Markus Suvanto wrote:
Now I notice that I can reproduce this index file corrupt only if
compress is enabled.
The file clone ioctl doesn't fully support cloning compressed inline
extents. IIRC the problem is that the clone ioctl can operate on an
arbitrary (block-aligned)
Markus,
This should fix your problem!
sage
---
Subject: [PATCH] Btrfs: fix arithmetic error in clone ioctl
Fix an arithmetic error that was breaking extents cloned via the clone
ioctl starting in the second half of a file.
Signed-off-by: Sage Weil s...@newdream.net
---
fs/btrfs/ioctl.c
-off-by: Sage Weil s...@newdream.net
---
fs/btrfs/extent-tree.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 90d314e..63d86ae 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -2813,7 +2813,7
Fix leak of vfsmount write reference and open_ioctl_trans reference on
ENOMEM. Clean up the error paths while we're at it.
Signed-off-by: Sage Weil s...@newdream.net
---
fs/btrfs/ioctl.c | 41 ++---
1 files changed, 22 insertions(+), 19 deletions(-)
diff
whoops, this doesn't apply, ignore! :)
--
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
Fix leak of vfsmount write reference and open_ioctl_trans reference on
ENOMEM. Clean up the error paths while we're at it.
Signed-off-by: Sage Weil s...@newdream.net
---
fs/btrfs/ioctl.c | 41 ++---
1 files changed, 22 insertions(+), 19 deletions(-)
diff
Hi everyone,
So, the btrfs user transaction ioctls work like so
ioctl(fd, BTRFS_IOC_TRANS_START);
/* do many operations: write(), setxattr(), rmdir(), whatever. */
ioctl(fd, BTRFS_IOC_TRANS_END);/* or close(fd); */
and allow an application to ensure some number of operations commit to
Pull out the actual free space check, so setting an inode's initial
space_info is done by the caller instead of a wonky goto.
Signed-off-by: Sage Weil s...@newdream.net
---
fs/btrfs/extent-tree.c | 81 +--
1 files changed, 50 insertions(+), 31
operations and thus btree modifications, for when
the metadata space reservation gets smarter.
Signed-off-by: Sage Weil s...@newdream.net
---
fs/btrfs/ctree.h |7
fs/btrfs/extent-tree.c | 57 --
fs/btrfs/ioctl.c | 92
Fix leak of vfsmount write reference and open_ioctl_trans reference on
ENOMEM. Clean up the error paths while we're at it.
Signed-off-by: Sage Weil s...@newdream.net
---
fs/btrfs/ioctl.c | 41 ++---
1 files changed, 22 insertions(+), 19 deletions(-)
diff
-by: Sage Weil s...@newdream.net
---
fs/btrfs/extent-tree.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index a4b2b03..d119c03 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -3168,7 +3168,7 @@ alloc
Hi Val!
On Wed, 7 Oct 2009, Valerie Aurora wrote:
On Fri, Sep 25, 2009 at 02:10:14PM -0700, Sage Weil wrote:
Hi everyone,
So, the btrfs user transaction ioctls work like so
ioctl(fd, BTRFS_IOC_TRANS_START);
/* do many operations: write(), setxattr(), rmdir(), whatever
we'd either need two passes, a big kmalloc, or
further trust the app to get the value right. (Same goes for the data
size, actually, although that's easier to get correct.)
Thoughts on this?
Thanks-
sage
Signed-off-by: Sage Weil s...@newdream.net
---
fs/btrfs/ioctl.c | 187
On Tue, 10 Nov 2009, Jeremy Fitzhardinge wrote:
On 11/10/09 14:13, Sage Weil wrote:
On Tue, 10 Nov 2009, Andrey Kuzmin wrote:
On Tue, Nov 10, 2009 at 11:12 PM, Sage Weil s...@newdream.net wrote:
Hi all,
This is an alternative approach to atomic user transactions for btrfs
On Wed, 11 Nov 2009, Chris Mason wrote:
On Tue, Nov 10, 2009 at 02:13:10PM -0800, Sage Weil wrote:
On Tue, 10 Nov 2009, Andrey Kuzmin wrote:
On Tue, Nov 10, 2009 at 11:12 PM, Sage Weil s...@newdream.net wrote:
Hi all,
This is an alternative approach to atomic user
On Wed, 11 Nov 2009, Zach Brown wrote:
I like this much more than providing a journal start/stop to userland.
If we can get Christoph to ack the exports we can work on the interface
in general.
I'll note, briefly, that it seems dangerous to call right into the sys_
functions instead of
On Tue, 8 Dec 2009, Josef Bacik wrote:
On Mon, Dec 07, 2009 at 02:25:50PM -0800, Sage Weil wrote:
When you create a new snap or subvol, first a new ROOT_ITEM is created
while everything commits, and then the referring directory entry is set up
(with a correspond ROOT_BACKREF
currently return -EINVAL when cloning a zero byte range at EOF (most
commonly when cloning a 0 byte file). Return success instead, even though
this is a no-op.
Signed-off-by: Sage Weil s...@newdream.net
---
fs/btrfs/ioctl.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git
On Tue, 12 Jan 2010, Chris Mason wrote:
On Tue, Jan 12, 2010 at 11:24:39AM -0800, Sage Weil wrote:
Hi Chris,
What is the motivation behind the two phases of snapshot creation
(create_pending_snapshot, finish_pending_snapshot)? Is it just to avoid
putting a reference to the snap
We were incorrectly taking the async path even for the sync ioctls by
passing in transid unconditionally.
There's ample room for further cleanup here, but this keeps the fix simple.
Signed-off-by: Sage Weil s...@newdream.net
---
fs/btrfs/ioctl.c | 20 +++-
1 files changed, 11
On Thu, 9 Dec 2010, Chris Mason wrote:
Excerpts from Li Zefan's message of 2010-12-09 21:11:25 -0500:
Sage Weil wrote:
We were incorrectly taking the async path even for the sync ioctls by
passing in transid unconditionally.
Ha, I fixed this accidentally in my patchset
Btrfs has no problems with lingering references to unlinked directory
inodes.
CC: Chris Mason chris.ma...@oracle.com
CC: linux-btrfs@vger.kernel.org
Signed-off-by: Sage Weil s...@newdream.net
---
fs/btrfs/inode.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/fs
Btrfs has no problems with lingering references to unlinked directory
inodes.
CC: Chris Mason chris.ma...@oracle.com
CC: linux-btrfs@vger.kernel.org
Signed-off-by: Sage Weil s...@newdream.net
---
fs/btrfs/inode.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/fs
On Fri, 10 Jun 2011, Chris Mason wrote:
Excerpts from Jim Schutt's message of 2011-06-10 13:06:22 -0400:
[ two different btrfs crashes ]
I think your two crashes in btrfs were from the uninit variables and
those should be fixed in rc2.
When I did my bisection, my criteria for
On Fri, 10 Jun 2011, Sage Weil wrote:
On Fri, 10 Jun 2011, Chris Mason wrote:
Excerpts from Jim Schutt's message of 2011-06-10 13:06:22 -0400:
[ two different btrfs crashes ]
I think your two crashes in btrfs were from the uninit variables and
those should be fixed in rc2
On Fri, 10 Jun 2011, Josef Bacik wrote:
On 06/10/2011 02:14 PM, Sage Weil wrote:
On Fri, 10 Jun 2011, Sage Weil wrote:
On Fri, 10 Jun 2011, Chris Mason wrote:
Excerpts from Jim Schutt's message of 2011-06-10 13:06:22 -0400:
[ two different btrfs crashes ]
I think your two crashes
On Fri, 10 Jun 2011, Josef Bacik wrote:
On 06/10/2011 02:35 PM, Sage Weil wrote:
On Fri, 10 Jun 2011, Josef Bacik wrote:
On 06/10/2011 02:14 PM, Sage Weil wrote:
On Fri, 10 Jun 2011, Sage Weil wrote:
On Fri, 10 Jun 2011, Chris Mason wrote:
Excerpts from Jim Schutt's message of 2011-06
Hey,
Is this something you guys have seen before? This is from v3.13-rc2.
kernel: [49432.696440] WARNING: CPU: 3 PID: 26411 at
/srv/autobuild-ceph/gitbuilder.git/build/fs/btrfs/extent-tree.c:5748
__btrfs_free_extent+0x9ce/0xa20 [btrfs]()
kernel: [49432.710128] Modules linked in: arc4(F)
On Thu, 28 Jul 2011, Christian Brunner wrote:
When I look at the latencytop results, there is a high latency when
calling btrfs_commit_transaction_async. Isn't async supposed to
return immediately?
It depends. That function has to block until the commit has started
before returning in the
Hi Christian,
Are you still seeing this slowness?
sage
On Wed, 27 Jul 2011, Christian Brunner wrote:
2011/7/25 Chris Mason chris.ma...@oracle.com:
Excerpts from Christian Brunner's message of 2011-07-25 03:54:47 -0400:
Hi,
we are running a ceph cluster with btrfs as it's base
Fix a crash/BUG_ON in the clone ioctl due to insufficient reservation. We
need to reserve space for:
- adjusting the old extent (possibly splitting it)
- adding the new extent
- updating the inode
Signed-off-by: Sage Weil s...@newdream.net
---
fs/btrfs/ioctl.c |7 ++-
1 files changed
Hi all,
I'm hitting a problem cloning inline extents that I haven't had much
success tracking down. It's simple enough to reproduce:
echo src
echo 2 dst
clone_range src 0 29 dst 0
cmp src dst # fails! dst is size 29 but contains 2\n\0\0\0\0...
where
On Tue, 9 Aug 2011, Sage Weil wrote:
Hi all,
I'm hitting a problem cloning inline extents that I haven't had much
success tracking down. It's simple enough to reproduce:
echo src
echo 2 dst
clone_range src 0 29 dst 0
cmp src dst # fails! dst
On Tue, 16 Aug 2011, Miao Xie wrote:
On tue, 9 Aug 2011 10:46:37 -0700, Sage Weil wrote:
Fix a crash/BUG_ON in the clone ioctl due to insufficient reservation. We
need to reserve space for:
- adjusting the old extent (possibly splitting it)
- adding the new extent
- updating
):
Btrfs: fix uninitialized sync_pending (+1/-1)
Btrfs: fix wrong free space information (+11/-5)
Sage Weil (1) commits (+4/-0):
Btrfs: truncate pages from clone ioctl target range
Tsutomu Itoh (1) commits (+16/-10):
Btrfs: forced readonly when btrfs_drop_snapshot() fails
when we read the file.
Disallow file clone if src and dst file have different checksum flag,
so we ensure a file is completely checksummed or unchecksummed.
Signed-off-by: Li Zefan l...@cn.fujitsu.com
Looks good to me.
Reviewed-by: Sage Weil s...@newdream.net
---
fs/btrfs/ioctl.c |5
On Tue, 13 Sep 2011, Liu Bo wrote:
On 09/11/2011 05:47 AM, Martin Mailand wrote:
Hi
I am hitting this Warning reproducible, the workload is a ceph osd,
kernel ist 3.1.0-rc5.
Have posted a patch for this:
http://marc.info/?l=linux-btrfsm=131547325515336w=2
We're still seeing this
On Thu, 15 Sep 2011, David Sterba wrote:
On Thu, Sep 15, 2011 at 03:50:29PM -0400, Josef Bacik wrote:
We're still seeing this with -rc6, which includes 98c9942 and 65450aa.
I haven't looked at the reservation code in much detail. Is there
anything I can do to help track this down?
On Fri, 16 Sep 2011, Li Zefan wrote:
It's a bug in commit f81c9cdc567cd3160ff9e64868d9a1a7ee226480
(Btrfs: truncate pages from clone ioctl target range)
We should pass the dest range to the truncate function, but not the
src range.
Sigh... yes.
Also move the function before locking extent
On Sun, 18 Sep 2011, Chris Mason wrote:
Excerpts from Sage Weil's message of 2011-09-16 12:39:06 -0400:
On Fri, 16 Sep 2011, Li Zefan wrote:
It's a bug in commit f81c9cdc567cd3160ff9e64868d9a1a7ee226480
(Btrfs: truncate pages from clone ioctl target range)
We should pass the dest
Hi Chris-
This pull misses the clone reservation fix again... :)
http://www.spinics.net/lists/linux-btrfs/msg11826.html
Thanks!
sage
On Mon, 19 Sep 2011, Chris Mason wrote:
Hi everyone,
The for-linus branch of the btrfs tree on github:
Head commit:
On Tue, 11 Oct 2011, Christian Brunner wrote:
2011/10/11 Sage Weil s...@newdream.net:
On Tue, 11 Oct 2011, Christian Brunner wrote:
Maybe this one is easier:
One of our OSDs isn't starting, because ther is no current
directory. What I have are three snap directories.
total 0
-rw-r
beyond just the Ceph related issues. Progress is slow, but we are
working on it!
sage
Kind regards,
Christian
2011/10/24 Sage Weil s...@newdream.net:
Although running on ext4, xfs, or whatever other non-btrfs you want mostly
works, there are a few important remaining issues:
1- ext4
On Tue, 25 Oct 2011, Christoph Hellwig wrote:
On Mon, Oct 24, 2011 at 10:06:49AM -0700, Sage Weil wrote:
- When I run ceph with btrfs snaps disabled, the situation is getting
slightly better. I can run an OSD for about 3 days without problems,
but then again the load increases. This time
On Tue, 25 Oct 2011, Josef Bacik wrote:
At this point it seems like the biggest problem with latency in ceph-osd
is not related to btrfs, the latency seems to all be from the fact that
ceph-osd is fsyncing a block dev for whatever reason.
There is one place where we sync_file_range() on the
On Tue, 25 Oct 2011, Christian Brunner wrote:
2011/10/25 Sage Weil s...@newdream.net:
On Tue, 25 Oct 2011, Josef Bacik wrote:
At this point it seems like the biggest problem with latency in ceph-osd
is not related to btrfs, the latency seems to all be from the fact that
ceph-osd
On Wed, 26 Oct 2011, Christian Brunner wrote:
2011/10/26 Sage Weil s...@newdream.net:
On Wed, 26 Oct 2011, Christian Brunner wrote:
Christian, have you tweaked those settings in your ceph.conf? It
would be
something like 'journal dio = false'. If not, can you verify
Otherwise we print FIRST_CHUNK_TREE for any objectid 256, which e.g. for
the root tree is the first snap/subvol.
Signed-off-by: Sage Weil s...@newdream.net
---
print-tree.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/print-tree.c b/print-tree.c
index 59f4358
and metadata (like 0-byte files)? If so, we should add
another ioctl for a full-blown snapshot so that users who _do_ want a
fully consistent snapshot can get it.
If not, something like the below should be sufficient to make all
snapshots fully consistent...
sage
---
From: Sage Weil s
Print a warning to the console when a btrfs ioctl transaction prematurely
commits a possibly partial result.
Signed-off-by: Sage Weil s...@newdream.net
---
fs/btrfs/file.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index 2e6404f
Signed-off-by: Sage Weil s...@newdream.net
---
fs/btrfs/ioctl.h | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/ioctl.h b/fs/btrfs/ioctl.h
index 32f86e4..4f7fe37 100644
--- a/fs/btrfs/ioctl.h
+++ b/fs/btrfs/ioctl.h
@@ -129,14 +129,14 @@ struct
key-type is u8, not u64.
fs/btrfs/ioctl.c: In function 'copy_to_sk':
fs/btrfs/ioctl.c:1024: warning: comparison is always true due to limited range
of data type
Signed-off-by: Sage Weil s...@newdream.net
---
fs/btrfs/ioctl.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff
proposals.
It's simpler, does the job, and the primitives should be useful for other
applications. Let me know what you think! I'm doing more testing this week,
but so far I haven't seen any problems with these changes.
Thanks-
sage
Sage Weil (5):
Btrfs: async transaction commit
Btrfs: add
).
Signed-off-by: Sage Weil s...@newdream.net
---
fs/btrfs/ctree.h |1 +
fs/btrfs/disk-io.c |1 +
fs/btrfs/transaction.c | 119
fs/btrfs/transaction.h |3 +
4 files changed, 124 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs
There is no reason (aside from user expectations that space be
freed RIGHT NOW) that transaction removing the root reference
commit immediately. Add an alternative ioctl that does not
commit immediately for those who don't need it to.
Signed-off-by: Sage Weil s...@newdream.net
---
fs/btrfs
).
Signed-off-by: Sage Weil s...@newdream.net
---
fs/btrfs/ioctl.c |7 +++
fs/btrfs/ioctl.h |4 +++-
2 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 7ea4ff0..fd824a7 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -885,6
Create a snap without waiting for it to commit to disk. The ioctl is
ordered such that subsequent operations will not be contained by the
created snapshot, and the commit is initiated, but the ioctl does not
wait for the snapshot to commit to disk.
Signed-off-by: Sage Weil s...@newdream.net
before the START_SYNC
reaches disk.
Signed-off-by: Sage Weil s...@newdream.net
---
fs/btrfs/ioctl.c | 34 +++
fs/btrfs/ioctl.h |2 +
fs/btrfs/transaction.c | 52
fs/btrfs/transaction.h |1 +
4 files
I'm no lockdep expert, but this appears to make the lockdep warning go
away for the i_mutex locking in the clone ioctl.
Signed-off-by: Sage Weil s...@newdream.net
---
fs/btrfs/ioctl.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs
it is not an error to drop the root reference and the root in the
same transaction, just drop the BUG_ON() in btrfs_del_root().
Signed-off-by: Sage Weil s...@newdream.net
---
fs/btrfs/root-tree.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/root-tree.c b/fs/btrfs/root-tree.c
On Wed, 9 Jun 2010, Roberto Ragusa wrote:
I hope that ideas about btrfs are not off-topic for this mailing list.
The forwarded message below was written by me on fedora-users.
The thread is about the ability to link two files in a manner
similar to cat 1 2 3 rm 1 2 while avoiding any data
On Sat, 12 Jun 2010, Jim Ursetto wrote:
Both `cp --reflink` and `bcp` sometimes round the file size up to the next
4k boundary, with the balance consisting of null bytes. At first glance
this behavior occurs for source file size 3916 bytes. I have tried this
with stock btrfs from kernel
the originally requested ending offset.
This bug was introduced by a22285a6 (2.6.35-rc1).
Signed-off-by: Sage Weil s...@newdream.net
---
fs/btrfs/ioctl.c | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 4cdb98c
is sticky. It is less strict than 'rm -rf subvol', which would
require scanning the entire subvol to ensure all content is deletable.
Signed-off-by: Sage Weil s...@newdream.net
---
fs/btrfs/ioctl.c | 25 ++---
1 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs
On Wed, 15 Sep 2010, Chris Ball wrote:
Hi,
Or make --sync the default behavior. This is probably what most
people are expecting anyway (similar to how standard filesystem
commands like rm work). Add an --aysnc option for those that
only care about knowing when the
On Wed, 15 Sep 2010, Sage Weil wrote:
For subvolume removal, racing doesn't seem like an issue. Why not just
do
# btrfs subvolume delete /path/to/subvolume1
# btrfs subvolume delete /path/to/subvolume2
# ...
# sync
?
Nevermind, read the whole thread this time. I'll defer to others
Hi Chris,
These are a few critical bug fixes for the clone ioctl. We've been
hitting these on a number of different systems, so getting these into
2.6.37 would be much appreciated.
Thanks!
sage
--
Sage Weil (1):
Btrfs: fix lockdep warning on clone ioctl
Yehuda Sadeh (2):
Btrfs: fix
From: Yehuda Sadeh yeh...@hq.newdream.net
The lookup_first_ordered_extent() was done on the wrong inode, and the
-delalloc_bytes test was wrong, as the following
btrfs_wait_ordered_range() would only invoke a range write and wouldn't
write the entire file data range. Also, a bad parameter was
From: Yehuda Sadeh yeh...@hq.newdream.net
We had an edge case issue where the requested range was just
following an existing extent. Instead of skipping to the next
extent, we used the previous one which lead to having zero
sized extents.
Signed-off-by: Yehuda Sadeh yeh...@hq.newdream.net
---
I'm no lockdep expert, but this appears to make the lockdep warning go
away for the i_mutex locking in the clone ioctl.
Signed-off-by: Sage Weil s...@newdream.net
---
fs/btrfs/ioctl.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs
On Mon, 18 Oct 2010, Goffredo Baroncelli wrote:
Hi all
like my previous patch, this one allow to remove a subvolume by an ordinary
user. Instead of adding this capability to the rmdir(2) syscall, I update the
BTRFS_IOC_SNAP_DESTROY ioctl, relaxing the rules to be execute.
The checks are
as I can do that, my
daemon doesn't have to run as root and I'm a happy camper. :)
If anybody has any questions or issues with any of this, please let me
know so I can revise the patches accordingly.
Thanks!
sage
---
Sage Weil (6):
Btrfs: fix deadlock in btrfs_commit_transaction
Btrfs
()) to decrement num_writers such that we wait
forever instead of for 1.
Fix this by deciding how long to wait when we wait.
Signed-off-by: Sage Weil s...@newdream.net
---
fs/btrfs/transaction.c | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/fs/btrfs
).
Signed-off-by: Sage Weil s...@newdream.net
---
fs/btrfs/ctree.h |1 +
fs/btrfs/disk-io.c |1 +
fs/btrfs/transaction.c | 119
fs/btrfs/transaction.h |3 +
4 files changed, 124 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs
1 - 100 of 145 matches
Mail list logo
