Re: yum upgrade on btrfs very slow

2009-09-29 Thread Tomasz Torcz
On Mon, Sep 28, 2009 at 09:35:43AM -0400, Chris Mason wrote: On Mon, Sep 28, 2009 at 02:18:27PM +0200, Tomasz Torcz wrote: Hi, I'm using btrfs as rootfs on my Fedora 12 (rawhide) test system. Every yum activity is very slow, like 15 minutes for installation of 11 packages 25MB in

Re: yum upgrade on btrfs very slow

2009-09-29 Thread Chris Mason
On Tue, Sep 29, 2009 at 08:18:22AM +0200, Tomasz Torcz wrote: On Mon, Sep 28, 2009 at 09:35:43AM -0400, Chris Mason wrote: On Mon, Sep 28, 2009 at 02:18:27PM +0200, Tomasz Torcz wrote: Hi, I'm using btrfs as rootfs on my Fedora 12 (rawhide) test system. Every yum activity is

Re: Clone range ioctl

2009-09-29 Thread Chris Mason
On Sat, Sep 26, 2009 at 04:46:20PM -0300, Alberto Bertogli wrote: Hi! Out of curiosity for btrfs, I'm modifying a project of mine (http://blitiri.com.ar/p/libjio) to use the clone range ioctl, and I've got a couple of questions. I thought this would be the place to ask them, I hope you

ENOSPC patches integrated into the master branch

2009-09-29 Thread Chris Mason
Hello everyone, A quick note that Josef's ENOSPC work is now integrated in the master branch of the btrfs-unstable repo. There is still a small window in his accounting where ENOSPC oopsen can creep in, but the code is doing very well here and the worst case estimates he uses are conservative

[PATCH 1/4] Btrfs: fix error cases for ioctl transactions

2009-09-29 Thread Sage Weil
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

[PATCH 2/4] Btrfs: fix deadlock with free space handling and user transactions

2009-09-29 Thread Sage Weil
If an ioctl-initiated transaction is open, we can't force a commit during the free space checks in order to free up pinned extents or else we deadlock. Just ENOSPC instead. A more satisfying solution that reserves space for the entire user transaction up front is forthcoming... Signed-off-by: