On Mon, 5 Feb 2018, David Sterba wrote:
> On Mon, Feb 05, 2018 at 05:52:52PM +0900, Wang Shilong wrote:
> >These ioctl are originally introduced by Sage Weil for Ceph use?
> > Not sure whether it still useful, Cc Sage just in case.
>
> We have checked that the ioctl is
EINVAL to the caller. This has been observed occasionally by
ceph-osd (which uses this ioctl heavily).
Fix by rechecking whether the provided transid <= last_trans_committed
after the search fails, and if so return 0.
Signed-off-by: Sage Weil
---
fs/btrfs/transaction.c | 12 +---
1 f
On Fri, 14 Mar 2014, Josef Bacik wrote:
> On 03/11/2014 07:44 PM, Sage Weil wrote:
> > 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-ce
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) md4(F)
On Fri, 18 Oct 2013, Chris Mason wrote:
> Quoting Sage Weil (2013-10-18 11:42:28)
> > On Fri, 18 Oct 2013, Josef Bacik wrote:
> > > On Thu, Oct 17, 2013 at 12:56:14PM -0700, Sage Weil wrote:
> > > > Hey,
> > > >
> > > > I'm seeing
On Fri, 18 Oct 2013, Josef Bacik wrote:
> On Thu, Oct 17, 2013 at 12:56:14PM -0700, Sage Weil wrote:
> > Hey,
> >
> > I'm seeing the deadlock below under a ceph-osd workload. There may be a
> > subtle problem with the async transaction sequence (since nobody but
Hey,
I'm seeing the deadlock below under a ceph-osd workload. There may be a
subtle problem with the async transaction sequence (since nobody but ceph
uses that that I know of), but not obvious to me why
create_pending_snapshots would get stuck on btrfs_tree_lock...
[ 602.217383] INFO: task
I just noticed that there is a locking imbalance warning with sb_internal
in the transaction commit code. I believe this has only started appearing
recently (after I merged -rc5 into my testing tree), but I'm working on
confirming that. The error is
<4>[27034.835134] ==
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
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 sn
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
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.
> >
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
> --- a
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 powercyclin
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 > /proc/sy
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
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 ]
2013-06-04T18:54:28.533002-07:
On Fri, 22 Mar 2013, Chris Mason wrote:
> Quoting Alexandre Oliva (2013-03-22 10:17:30)
> > On Mar 22, 2013, Chris Mason wrote:
> >
> > > Are you using compression in btrfs or just in leveldb?
> >
> > btrfs lzo compression.
>
> Perfect, I'll focus on that part of things.
>
> >
> > > I'd like
On Tue, 19 Mar 2013, Chris Mason wrote:
> Quoting Alexandre Oliva (2013-03-19 01:20:10)
> > On Mar 18, 2013, Chris Mason wrote:
> >
> > > A few questions. Does leveldb use O_DIRECT and mmap together?
> >
> > No, it doesn't use O_DIRECT at all. Its I/O interface is very
> > simplified: it just
Acked-by: Sage Weil
On Mon, 11 Feb 2013, Namjae Jeon wrote:
> From: Namjae Jeon
>
> This patch is a follow up on below patch:
>
> [PATCH] exportfs: add FILEID_INVALID to indicate invalid fid_type
> commit: 216b6cbdcbd86b1db0754d58886b466ae31f5a63
>
> Signed-off-b
On Wed, 30 Jan 2013, Josef Bacik wrote:
> On Wed, Jan 30, 2013 at 11:30:49AM -0700, Mike Lowe wrote:
> > I've been running rsync against a rbd device backed by btrfs filesystems
> > that are about 11% full for about 45 minutes before I checked and noticed
> > the printk message. That was the fir
A ceph user observed a incorrect i_size on btrfs. The pattern looks like
this:
- some writes at low file offsets
- a write to 4185600 len 8704 (i_size should be 4MB)
- more writes to low offsets
- a write to 4181504 len 4096 (abutts the write above)
- a bit of time goes by...
- stat returns 4186
in the
> __btrfs_end_transaction. Moving the sb_end_intewrite after this logic makes
> the
> lockdep go away. Thanks,
>
> Signed-off-by: Josef Bacik
This appears to have done the trick (at least so far). I'm running it on
top of -rc5 and the 3 patches I posted on Aug 30t
destroy_delayed_refs.isra.102+0x220/0x220 [btrfs]
[ 607.104740] [] kthread+0xae/0xc0
[ 607.137119] [] ? trace_hardirqs_on+0xd/0x10
[ 607.169797] [] kernel_thread_helper+0x4/0x10
[ 607.202472] [] ? retint_restore_args+0x13/0x13
[ 607.235884] [] ? flush_kthread_work+0x1a0/0x1a0
[ 607.268731] []
/xfs_aops.c.
Signed-off-by: Sage Weil
---
fs/btrfs/transaction.c | 16
1 file changed, 16 insertions(+)
diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
index 17be3de..efc41a5 100644
--- a/fs/btrfs/transaction.c
+++ b/fs/btrfs/transaction.c
@@ -1228,6 +1228,14
We expect current->journal_info to point to the trans handle we are
committing.
Signed-off-by: Sage Weil
---
fs/btrfs/transaction.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
index efc41a5..f910a26 100644
--- a/fs/btrfs/transactio
These three patches (in combination with btrfs-next) fix things up for me!
Sage Weil (3):
Btrfs: pass lockdep rwsem metadata to async commit transaction
Btrfs: set journal_info in async trans commit worker
Btrfs: do not take cleanup_work_sem in btrfs_run_delayed_iputs()
fs/btrfs/inode.c
On Sun, 26 Aug 2012, Josef Bacik wrote:
> On Fri, Aug 24, 2012 at 04:47:56PM -0600, Sage Weil wrote:
> > Sadly, now I hit another one:
> >
>
> Oh haha you need to set current->journal_info to the trans you have before you
> call commit_transaction in do_async_commit
tore_args+0x13/0x13
[ 378.434368] [] ? flush_kthread_work+0x1a0/0x1a0
[ 378.434371] [] ? gs_change+0x13/0x13
On Fri, 24 Aug 2012, Sage Weil wrote:
> The freeze rwsem is taken by sb_start_intwrite() and dropped during the
> commit_ or end_transaction(). In the async case, that happens
d-off-by: Sage Weil
---
fs/btrfs/transaction.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
index 17be3de..efc41a5 100644
--- a/fs/btrfs/transaction.c
+++ b/fs/btrfs/transaction.c
@@ -1228,6 +1228,14 @@ s
Hi Stefan,
I haven't seen this one. The async commit stuff is mine, but there
haven't been problems with it for a year or more. This is a recent
kernel, I assume?
Can you dump the other tasks? Something is preventing the commit from
completing.
[adding linux-btrfs to cc]
sage
On Fri, 2
On Tue, 24 Apr 2012, Josef Bacik wrote:
> On Fri, Apr 20, 2012 at 05:09:34PM +0200, Christian Brunner wrote:
> > After running ceph on XFS for some time, I decided to try btrfs again.
> > Performance with the current "for-linux-min" branch and big metadata
> > is much better. The only problem (?) I
On Fri, 10 Feb 2012, Josef Bacik wrote:
> On Fri, Feb 10, 2012 at 11:25:27AM -0800, Sage Weil wrote:
> > Hi everyone,
> >
> > The takeaway from the 'stable pages' discussions in the last few workshops
> > was that pages under writeback should remain locked
Hi everyone,
The takeaway from the 'stable pages' discussions in the last few workshops
was that pages under writeback should remain locked so that subsequent
writers don't touch them while they are en route to the disk. This
prevents bad checksums and DIF/DIX type failures (whereas previously
I've made a little progress here. The rmdir succeeds and successfully
adds the orphan item to the tree. Shortly after that, we (async) snapshot
current/ to snap_127294/. And then the orphan cleanup gets
[87552.240450] [ cut here ]
[87552.240477] WARNING: at
/srv/autob
On Fri, 27 Jan 2012, Chris Mason wrote:
> On Fri, Jan 27, 2012 at 09:31:46AM -0800, Sage Weil wrote:
> > Has anyone see this one before? We've been hitting it sporatically for a
> > while now, although recently we've been able to trigger pretty easily.
> > The
Has anyone see this one before? We've been hitting it sporatically for a
while now, although recently we've been able to trigger pretty easily.
The result is EINVAL from the snap create ioctl.
The kernel is v3.2 + some ceph stuff.
The code in question is
/* if we have links,
On Wed, 26 Oct 2011, Christian Brunner wrote:
> 2011/10/26 Sage Weil :
> > On Wed, 26 Oct 2011, Christian Brunner wrote:
> >> >> > Christian, have you tweaked those settings in your ceph.conf? It
> >> >> > would be
> >> >> > som
On Tue, 25 Oct 2011, Christian Brunner wrote:
> 2011/10/25 Sage Weil :
> > 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
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 t
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
s at the moment, and are
still struggling to hire experienced kernel/fs people. Josef has been
very helpful with tracking these issues down, but he hass responsibilities
beyond just the Ceph related issues. Progress is slow, but we are
working on it!
sage
>
> Kind regards,
> Chri
On Tue, 11 Oct 2011, Christian Brunner wrote:
> 2011/10/11 Sage Weil :
> > 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"
> >> director
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: a66e7cc626f42de6c745963
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 p
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 e
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
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-btrfs&m=131547325515336&w=2
We're still
mmed and the other part is not,
> and then btrfs will complain checksum is not found 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 Zefa
;
> Li Zefan (1) commits (+2/-4):
> Btrfs: use plain page_address() in header fields setget functions
>
> Miao Xie (2) commits (+12/-6):
> Btrfs: fix uninitialized sync_pending (+1/-1)
> Btrfs: fix wrong free space information (+11/-5)
>
> Sage Weil (1) commi
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)
&
We need to truncate page cache pages for the clone ioctl target range or
else we'll confuse ourselves to no end. If the old data was cached, we
used to still see it (until remount). If the page was partially updated
we used to get a mix of old and new data.
Signed-off-by: Sage Weil
---
v
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
&g
We need to truncate page cache pages for the clone ioctl target range or
else we'll confuse ourselves to no end. If the old data was cached, we'll
still see it (until remount). If it was dirty we'll get a mix of old and
new data if the page(s) are partially updated.
Signed-of
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
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
---
fs/btrfs/ioctl.c |7 ++-
1 files changed, 6 insertions
Hi Christian,
Are you still seeing this slowness?
sage
On Wed, 27 Jul 2011, Christian Brunner wrote:
> 2011/7/25 Chris Mason :
> > 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 filesystem
> >> (ke
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
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 Ma
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:
> >>>
>
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 vari
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 s
Btrfs has no problems with lingering references to unlinked directory
inodes.
CC: Chris Mason
CC: linux-btrfs@vger.kernel.org
Signed-off-by: Sage Weil
---
fs/btrfs/inode.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index
Btrfs has no problems with lingering references to unlinked directory
inodes.
CC: Chris Mason
CC: linux-btrfs@vger.kernel.org
Signed-off-by: Sage Weil
---
fs/btrfs/inode.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index
Hi Chris,
On Tue, 8 Feb 2011, Chris Dunlop wrote:
> On Mon, Feb 07, 2011 at 06:39:11PM +1100, Chris Dunlop wrote:
> > On Mon, Feb 07, 2011 at 05:31:02PM +1100, Chris Dunlop wrote:
> >> G'day,
> >>
> >> Using Josef's btrfs-work bacae123 (+ ceph-client 9aae8faf), I
> >> can consistently reproduce t
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.
> > >
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
---
fs/btrfs/ioctl.c | 20 +++-
1 files changed, 11 inserti
Hi Chris,
Is this ioctl change destined for 2.6.37? If it (or something similar)
looks good it should probably be merged (independent of the rest of the
series) this time around before we're stuck with the current version.
Thanks-
sage
On Mon, 29 Nov 2010, Li Zefan wrote:
> So we don't have
Hi Li,
On Mon, 29 Nov 2010, Li Zefan wrote:
> So we don't have to add new structures as we create more ioctls
> for snapshots.
>
> Now to create async snapshot, set BTRFS_SNAPSHOT_CREATE_ASYNC bit of
> vol_arg_v2->flags, and then call ioctl(BTRFS_IOCT_SNAP_CREATE_V2).
>
> Note: this changes the
len) & (bs-1)))
> + if (!IS_ALIGNED(off, bs) || !IS_ALIGNED(off + len, bs) ||
> + !IS_ALIGNED(destoff, bs))
> goto out_unlock;
>
> /* do any pending delalloc/csum calc on src, one way or
Looks good.
Reviewed-by: Sage Weil
--
To unsubscribe fr
n)
> + endoff = destoff+olen;
> if (endoff > inode->i_size)
> btrfs_i_size_write(inode, endoff);
Reviewed-by: Sage Weil
--
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
Hey,
I saw a few variations of this lockdep on about a dozen different nodes
running 2.6.37-rc1+ (mainline from earlier this week). They all look to
be the same issue, hit via a few different call paths. I haven't seen
these before...
sage
[10862.369802] ===
On Tue, 2 Nov 2010, Goffredo Baroncelli wrote:
> Like the command "btrfs subvol snapshot", I think that it is better to add a
> modifier instead of a new command.
>
> btrfs filesystem sync [--async]
>
> Sorry if I noticed this too late. But I don't see a valid reason to add
> another command.
On Tue, 2 Nov 2010, Goffredo Baroncelli wrote:
> On Monday, 01 November, 2010, Sage Weil wrote:
> > On Sat, 30 Oct 2010, Goffredo Baroncelli wrote:
> > > On Saturday, 30 October, 2010, Sage Weil wrote:
> > > > This is identical to 'snapshot', but
lized from here
when building with gcc version 4.4.4 (Debian 4.4.4-6).
Signed-off-by: Sage Weil
---
ioctl.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/ioctl.h b/ioctl.h
index 5a03317..4a850ff 100644
--- a/ioctl.h
+++ b/ioctl.h
@@ -87,7 +87,7 @@ struct btrfs_ioctl
Add an 'async' option to the snapshot creating command, that will let you
avoid waiting for a new snapshot to commit to disk.
Signed-off-by: Sage Weil
---
btrfs.c|9 ++---
btrfs_cmds.c | 31 +--
btrfs_cmds.h |2 +-
man/btrfs.8
nc snapshot creation to commit.
Updates the man page too.
Signed-off-by: Sage Weil
---
btrfs.c|9 +
btrfs_cmds.c | 49 +
btrfs_cmds.h |2 ++
man/btrfs.8.in | 14 ++
4 files changed, 74 insertions(+)
On Sat, 30 Oct 2010, Goffredo Baroncelli wrote:
> On Saturday, 30 October, 2010, Sage Weil wrote:
> > This is identical to 'snapshot', but uses the new async snapshot creation
> > ioctl, and prints out the transid the new snapshot will be committed
> > with.
&g
On Sat, 30 Oct 2010, Goffredo Baroncelli wrote:
> On Saturday, 30 October, 2010, Sage Weil wrote:
> > This is identical to 'snapshot', but uses the new async snapshot creation
> > ioctl, and prints out the transid the new snapshot will be committed
> > with.
>
ync snapshot creation to commit.
Signed-off-by: Sage Weil
---
btrfs.c |9 +
btrfs_cmds.c | 49 +
btrfs_cmds.h |2 ++
3 files changed, 60 insertions(+), 0 deletions(-)
diff --git a/btrfs.c b/btrfs.c
index c4b9a31..d45ac1f 100
Signed-off-by: Sage Weil
---
ioctl.h | 39 ++-
1 files changed, 30 insertions(+), 9 deletions(-)
diff --git a/ioctl.h b/ioctl.h
index 776d7a9..5a03317 100644
--- a/ioctl.h
+++ b/ioctl.h
@@ -23,13 +23,28 @@
#define BTRFS_IOCTL_MAGIC 0x94
#define
This is identical to 'snapshot', but uses the new async snapshot creation
ioctl, and prints out the transid the new snapshot will be committed
with.
Signed-off-by: Sage Weil
---
btrfs.c |8 +++-
btrfs_cmds.c | 32 +++-
btrfs_cmds.h |3 ++
additionally require that the user has write+exec permission on the
subvol root inode.
Signed-off-by: Sage Weil
---
v2:
- add write+exec check on subvol root inode
fs/btrfs/ctree.h |1 +
fs/btrfs/ioctl.c | 115 +++--
fs/btrfs/super.c |6
nsaction()) to decrement num_writers such that we wait
forever instead of for 1.
Fix this by deciding how long to wait when we wait. Include a smp_mb()
before checking if the waitqueue is active to ensure the num_writers
is visible.
Signed-off-by: Sage Weil
---
v2:
- add smp_mb(
On Tue, 26 Oct 2010, Goffredo Baroncelli wrote:
> > inode = dentry->d_inode;
> > + dest = BTRFS_I(inode)->root;
> > + if (!capable(CAP_SYS_ADMIN)){
> > + /*
> > +* Regular user. Only allow this with a special mount
> > +* option, and when rmdir(2) would ha
On Tue, 26 Oct 2010, liubo wrote:
> On 10/26/2010 03:07 AM, Sage Weil wrote:
> > We calculate timeout (either 1 or MAX_SCHEDULE_TIMEOUT) based on whether
> > num_writers > 1 or should_grow at the top of the loop. Then, much much
> > later, we wait for that timeout
).
Signed-off-by: Sage Weil
---
fs/btrfs/ctree.h |1 +
fs/btrfs/ioctl.c | 109 +++--
fs/btrfs/super.c |6 ++-
3 files changed, 110 insertions(+), 6 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 5ac2bca..140003e 100644
--- a
On Mon, 25 Oct 2010, Chris Mason wrote:
> Yes, lets duplicate the vfs checks. Christoph just sat bolt upright in
> whatever ski lift he's currently riding.
:)
This version is based on Goffredo's patch, but requires the
user_subvol_rm_allowed mount option, and will proceed even if the subvol
is
On Mon, 25 Oct 2010, Chris Mason wrote:
> These all look good to me and I'm pulling them in.
Great, thanks!
> > The last item is a change to SNAP_DESTROY to allow deletion of a
> > snapshot when the user owns the subvol's root inode and the parent
> > directory permissions are such that we woul
equirements if the parent
directory 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
---
fs/btrfs/ioctl.c| 27 ---
security/security.c |1 +
2
ation completed before the START_SYNC
reaches disk.
Signed-off-by: Sage Weil
---
fs/btrfs/ioctl.c | 34 +++
fs/btrfs/ioctl.h |2 +
fs/btrfs/transaction.c | 52
fs/btrfs/transaction.h |1 +
4 fi
that an application can wait
for this specific snapshot creation to commit via the WAIT_SYNC ioctl.
Signed-off-by: Sage Weil
---
fs/btrfs/ioctl.c | 89 ++
fs/btrfs/ioctl.h |7
2 files changed, 83 insertions(+), 13 deletions(-)
diff
;.
Signed-off-by: Sage Weil
---
fs/btrfs/ioctl.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 679b8a8..9cbda86 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -1365,7 +1365,7 @@ static noinline int btrfs_ioctl_sn
nsaction()) 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
---
fs/btrfs/transaction.c | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/fs/btrfs/transaction.c b/
t creation).
Signed-off-by: Sage Weil
---
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/ct
-root user. As long 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 bt
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
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
---
fs/btrfs/ioctl.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index f4
From: Yehuda Sadeh
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 passed to
btrfs_wait_
From: Yehuda Sadeh
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
---
fs/btrfs/ioctl.c |2 +-
1 files changed, 1
1 - 100 of 185 matches
Mail list logo
