date:20110804

On Thu, Aug 04, 2011 at 10:45:30AM +0100, Leonidas Spyropoulos wrote:
 Why the official repository is not updated with the latest patched for gcc 
 4.6?
 I noticed that http://git.darksatanic.net/repo/btrfs-progs-unstable.git/
 includes more patches than the
 git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git
 
 So I was wondering is it some kind of testing to be done on patches to
 be included into the official repo?

   There have been a lot of patches published in the 9 months or so
since the upstream repo was last updated -- Chris has been
concentrating on other things (like kernel-side stability and the new
fsck). I pulled them all into one place and started to try to make
sense of them all, which is the ongoing work that is the darksatanic
repo.

   There's a for-chris branch (which is actually the same as my master
branch now), which is the stable patches that have (mostly) been
reviewed. Then there's the integration-* branches, which are general
dumps of things that aren't ready to go upstream yet, but which I'm
publishing simply to get patches available for testing (particularly
new features like scrub).

   I should probably send Chris another pull request. :)

 Another thing is that there are commands for creating the build
 enviroment for fedora and debian but I found nowhere in the wiki the
 dependencies of the btrfs-progs to compile them.
 Shouldn't be a list of packages or dependencies for it?

   The website is a wiki, so feel free to update the instructions with
anything you've found to be missing. And I'll happily accept patches
to any instructions that are shipped with the userspace tools. :)

   (I believe the only dependencies are libuuid and libxattr --
whatever they're called on $distribution).

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- emacs:  Eighty Megabytes And Constantly Swapping. ---


signature.asc
Description: Digital signature

INSTALL hint: create device btrfs-control

Hallo,

you should please add a hint in

   .../git/mason/btrfs-progs-unstable.git

in the file INSTALL with at least the contents (please excuse my  
gerlish)

btrfs needs the device btrfs-control. Perhaps you have to create it:

mknod /dev/btrfs-control c 10 234

Viele Gruesse!
Helmut
--
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

Re: btrfs-progs repository

2011-08-04 Thread Leonidas Spyropoulos

On Thu, Aug 4, 2011 at 11:01 AM, Hugo Mills h...@carfax.org.uk wrote:
 On Thu, Aug 04, 2011 at 10:45:30AM +0100, Leonidas Spyropoulos wrote:
 Why the official repository is not updated with the latest patched for gcc 
 4.6?
 I noticed that http://git.darksatanic.net/repo/btrfs-progs-unstable.git/
 includes more patches than the
 git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git

 So I was wondering is it some kind of testing to be done on patches to
 be included into the official repo?

   There have been a lot of patches published in the 9 months or so
 since the upstream repo was last updated -- Chris has been
 concentrating on other things (like kernel-side stability and the new
 fsck). I pulled them all into one place and started to try to make
 sense of them all, which is the ongoing work that is the darksatanic
 repo.

   There's a for-chris branch (which is actually the same as my master
 branch now), which is the stable patches that have (mostly) been
 reviewed. Then there's the integration-* branches, which are general
 dumps of things that aren't ready to go upstream yet, but which I'm
 publishing simply to get patches available for testing (particularly
 new features like scrub).

   I should probably send Chris another pull request. :)
The only reason for me to search the mailing list for an alternative
repository (and I send the message after) was because with the latest
stable gcc 4.6 it doesn't compile due to some unused variables
(WARNINGS) so your repository seems to compile fine.
I wasn't after some cool new untested feature tbh, just the latest
btrfs. Would be cool to update it.

 Another thing is that there are commands for creating the build
 enviroment for fedora and debian but I found nowhere in the wiki the
 dependencies of the btrfs-progs to compile them.
 Shouldn't be a list of packages or dependencies for it?

   The website is a wiki, so feel free to update the instructions with
 anything you've found to be missing. And I'll happily accept patches
 to any instructions that are shipped with the userspace tools. :)
I would be happy to update the wiki if I knew the dependencies :P
And I don't know what you mean with the patched to userspace tools,
sorry for my naiveness.
(even If I make a patch I don't know how to actually produce the
standartize patch mails I see on the mailing list, but that's out of
the mailing list question; would be grateful in an off-the-list email
with instructions).


   (I believe the only dependencies are libuuid and libxattr --
 whatever they're called on $distribution).
No idea and when I searched on Arch linux for those packages didn't
find any with that name, should be under another package.


   Hugo.

 --
 === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
        --- emacs:  Eighty Megabytes And Constantly Swapping. ---

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)

 iD8DBQFOOm4GIKyzvlFcI40RAhsRAJ9G+zIkvJcOAxJp/bACRlLFYqbwIwCggMaU
 mMaunZQG3NDI4yazFuC517Y=
 =GQRp
 -END PGP SIGNATURE-





-- 
Caution: breathing may be hazardous to your health.
--
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

Re: btrfs-progs repository

Hallo, Leonidas,

Du meintest am 04.08.11:

 Another thing is that there are commands for creating the build
 enviroment for fedora and debian but I found nowhere in the wiki the
 dependencies of the btrfs-progs to compile them.
 Shouldn't be a list of packages or dependencies for it?

Have you already studied the INSTALL file?

Viele Gruesse!
Helmut
--
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

Re: Metadata space in BTRFS

[cc linux-btrfs added]

On Thu, Aug 04, 2011 at 01:42:34AM +0200, JA Magallon wrote:
 Hi all...
 
 Just a simple question.
 I'm trying to use a 16GB SDHC card formatted in btrfs, and the system
 eats about 2GB for its metadata space. When the card fills, the
 situation is like this:
 
 werewolf:/media/home# btrfs fi df .
 Data: total=13.22GB, used=13.22GB
 System, DUP: total=8.00MB, used=4.00KB
 System: total=4.00MB, used=0.00
 Metadata, DUP: total=1.00GB, used=58.43MB
 Metadata: total=8.00MB, used=0.00
 
 I lose about 2Gb wrt ext4. Is there any way to shrink this metadata
 space ?
 
 TIA
 

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- But somewhere along the line, it seems / That pimp became ---
   cool,  and punk mainstream.   


signature.asc
Description: Digital signature

Re: btrfs-progs repository

2011-08-04 Thread Leonidas Spyropoulos

On Thu, Aug 4, 2011 at 11:14 AM, Helmut Hullen hul...@t-online.de wrote:
 Hallo, Leonidas,

 Du meintest am 04.08.11:

 Another thing is that there are commands for creating the build
 enviroment for fedora and debian but I found nowhere in the wiki the
 dependencies of the btrfs-progs to compile them.
 Shouldn't be a list of packages or dependencies for it?

 Have you already studied the INSTALL file?
Right, it's mentioned there must have missed it when I read the
INSTALL months ago..
I didn't think it would change :P


 Viele Gruesse!
 Helmut
 --
 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




-- 
Caution: breathing may be hazardous to your health.
--
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

Re: [GIT PULL v3] Btrfs: improve write ahead log with sub transaction

Excerpts from Liu Bo's message of 2011-06-21 04:49:41 -0400:
 I've been working to try to improve the write-ahead log's performance,
 and I found that the bottleneck addresses in the checksum items,
 especially when we want to make a random write on a large file, e.g a 4G file.

I spent some time last week on this code, because I really wanted to
be able to include it.  But I hit two problems.

Recording the transid of the log tree root doesn't completely solve
problems with later mounts expecting generation + 1.  If an older kernel
were to try and mount a log created by our new code, it wouldn't
understand the transid and the mount would fail.

I think we just need to force the transid of the root block to
generation + 1.  It is slightly less optimal but still much better than
what we have.

The second problem was that I consistently hit crashes during log replay
after a crash.  The test was just to use synctest:

http://oss.oracle.com/~mason/synctest/

synctest -t 32 -f -F -u -n 100 /mnt

I waited about 45 seconds and reset the machine.  Later mounts would
crash during log replay.

-chris

 
 Then a idea for this suggested by Chris is to use sub transaction ids and just
 to log the part of inode that had changed since either the last log commit or
 the last transaction commit.  And as we also push the sub transid into the 
 btree
 blocks, we'll get much faster tree walks.  As a result, we abandon the 
 original
 brute force approach, which is to delete all items of the inode in log,
 to making sure we get the most uptodate copies of everything, and instead
 we manage to find and merge, i.e. finding extents in the log tree and 
 merging
 in the new extents from the file.
 
 This patchset puts the above idea into code, and although the code is now more
 complex, it brings us a great deal of performance improvement:
 
 in my sysbench write + fsync test:
 
 451.01Kb/sec - 4.3621Mb/sec
 
 In v2, thanks to Chris, we worked together to solve 2 bugs, and after that it
 works as expected.
 
 Since there are some vital changes in recent rc, like kill trans_mutex and
 use cur_trans, as David asked, I rebase the patchset to the latest for-linus
 branch.
 
 More tests are welcome!
 
 You can also get this patchset from:
 
 git://repo.or.cz/linux-btrfs-devel.git sub-trans
 
 Liu Bo (12):
   Btrfs: introduce sub transaction stuff
   Btrfs: update block generation if should_cow_block fails
   Btrfs: modify btrfs_drop_extents API
   Btrfs: introduce first sub trans
   Btrfs: still update inode trans stuff when size remains unchanged
   Btrfs: improve log with sub transaction
   Btrfs: add checksum check for log
   Btrfs: fix a bug of log check
   Btrfs: kick off useless code
   Btrfs: deal with EEXIST after iput
   Btrfs: use the right generation number to read log_root_tree
   Revert Btrfs: do not flush csum items of unchanged file data during
 treelog
 
  fs/btrfs/btrfs_inode.h |   12 ++-
  fs/btrfs/ctree.c   |   69 +---
  fs/btrfs/ctree.h   |5 +-
  fs/btrfs/disk-io.c |   12 +-
  fs/btrfs/extent-tree.c |   10 +-
  fs/btrfs/file.c|   22 ++---
  fs/btrfs/inode.c   |   33 ---
  fs/btrfs/ioctl.c   |6 +-
  fs/btrfs/relocation.c  |6 +-
  fs/btrfs/transaction.c |   14 ++-
  fs/btrfs/transaction.h |   19 +++-
  fs/btrfs/tree-defrag.c |2 +-
  fs/btrfs/tree-log.c|  272 ++-
  13 files changed, 331 insertions(+), 151 deletions(-)
--
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

Re: Hot rb_next, setup_cluster_no_bitmap

Excerpts from Simon Kirby's message of 2011-08-03 21:32:10 -0400:
 Perhaps as a further clue as to what is going on, on this same backup box
 after all of the rsyncs are finished/killed and a good amount of time has
 passed (no cleaner processes running in the background or anything),
 sync is still consistently takes ~4 minutes to run, and pushes out a
 lot to disk every time it is run. Example:
 
 echo 3  /proc/sys/vm/drop_caches
 sync
 echo 3  /proc/sys/vm/drop_caches
 sync
 vmstat 1 
 time sync

Just to confirm, the profiling during this time shows your system time
is all in rb_next?

-chris
--
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

Re: Btrfs Slowdown (due to Memory Handling?)

Excerpts from Mitch Harder's message of 2011-08-02 10:35:54 -0400:
 I'm running into a significant slowdown in Btrfs ( 10x slower than
 normal) that appears to be due to some issue between how Btrfs is
 allocating memory, and how the kernel is expecting Btrfs to allocate
 memory.
 
 The problem does seem to be somewhat hardware specific.  I can
 reproduce on two of my computers (an older AMD Athlon(tm) XP 2600+
 with PATA, and a newer ACER Aspire netbook with an Atom CPU).  My
 Core2Duo computer with SATA seems unaffected by this slowdown.
 
 I've replicated this on 2.6.38, 2.6.39, and 3.0 kernels.  The
 following information was all obtained running on a 3.0 kernel merged
 with the latest 'for-linus' branch of Chris' git repo.  I've also
 tested on ext4 (no slow down encountered) to make sure the issue
 wasn't completely unrelated to Btrfs.

Just to double check, what was the top commit of for-linus when you did
this?

The tracing shows that you're spending your time in mmap'd readahead.
So one of three things is happening:

1) The VM is favoring our metadata over data pages for the git packed
file

2) We're reading ahead too aggressively, or not aggressively enough

3) The git pack file is somehow more fragmented, and this is making the
read ahead much less effective.

The very first thing I'd check is to make sure the .git repo between the
slow machines and the fast machines are identical.  Git does a lot of
packing behind the scenes, and so an older repo that isn't freshly
cloned is going to be slower than a new repo.

-chris
--
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

[PATCH] Btrfs: detect wether a device supports discard

2011-08-04 Thread Josef Bacik

We have a problem where if a user specifies discard but doesn't actually support
it we will return EOPNOTSUPP from btrfs_discard_extent.  This is a problem
because this gets called (in a fashion) from the tree log recovery code, which
has a nice little BUG_ON(ret) after it, which causes us to fail the tree log
replay.  So instead detect wether our devices support discard when we're adding
them and then don't issue discards if we know that the device doesn't support
it.  And just for good measure set ret = 0 in btrfs_issue_discard just in case
we still get EOPNOTSUPP so we don't screw anybody up like this again.  Thanks,

Signed-off-by: Josef Bacik jo...@redhat.com
---
 fs/btrfs/extent-tree.c |   12 ++--
 fs/btrfs/volumes.c |   17 +
 fs/btrfs/volumes.h |2 ++
 3 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index ca57fdc..3d3a4b3 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -1797,6 +1797,9 @@ int btrfs_discard_extent(struct btrfs_root *root, u64 
bytenr, u64 num_bytes,
 
 
for (i = 0; i  multi-num_stripes; i++, stripe++) {
+   if (!stripe-dev-can_discard)
+   continue;
+
ret = btrfs_issue_discard(stripe-dev-bdev,
  stripe-physical,
  stripe-length);
@@ -1804,11 +1807,16 @@ int btrfs_discard_extent(struct btrfs_root *root, u64 
bytenr, u64 num_bytes,
discarded_bytes += stripe-length;
else if (ret != -EOPNOTSUPP)
break;
+
+   /*
+* Just in case we get back EOPNOTSUPP for some reason,
+* just ignore the return value so we don't screw up
+* people calling discard_extent.
+*/
+   ret = 0;
}
kfree(multi);
}
-   if (discarded_bytes  ret == -EOPNOTSUPP)
-   ret = 0;
 
if (actual_bytes)
*actual_bytes = discarded_bytes;
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index b89e372..8af3bf9 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -500,6 +500,9 @@ static int __btrfs_close_devices(struct btrfs_fs_devices 
*fs_devices)
fs_devices-rw_devices--;
}
 
+   if (device-can_discard)
+   fs_devices-num_can_discard--;
+
new_device = kmalloc(sizeof(*new_device), GFP_NOFS);
BUG_ON(!new_device);
memcpy(new_device, device, sizeof(*new_device));
@@ -508,6 +511,7 @@ static int __btrfs_close_devices(struct btrfs_fs_devices 
*fs_devices)
new_device-bdev = NULL;
new_device-writeable = 0;
new_device-in_fs_metadata = 0;
+   new_device-can_discard = 0;
list_replace_rcu(device-dev_list, new_device-dev_list);
 
call_rcu(device-rcu, free_device);
@@ -547,6 +551,7 @@ int btrfs_close_devices(struct btrfs_fs_devices *fs_devices)
 static int __btrfs_open_devices(struct btrfs_fs_devices *fs_devices,
fmode_t flags, void *holder)
 {
+   struct request_queue *q;
struct block_device *bdev;
struct list_head *head = fs_devices-devices;
struct btrfs_device *device;
@@ -603,6 +608,12 @@ static int __btrfs_open_devices(struct btrfs_fs_devices 
*fs_devices,
seeding = 0;
}
 
+   q = bdev_get_queue(bdev);
+   if (blk_queue_discard(q)) {
+   device-can_discard = 1;
+   fs_devices-num_can_discard++;
+   }
+
device-bdev = bdev;
device-in_fs_metadata = 0;
device-mode = flags;
@@ -1542,6 +1553,7 @@ error:
 
 int btrfs_init_new_device(struct btrfs_root *root, char *device_path)
 {
+   struct request_queue *q;
struct btrfs_trans_handle *trans;
struct btrfs_device *device;
struct block_device *bdev;
@@ -1611,6 +1623,9 @@ int btrfs_init_new_device(struct btrfs_root *root, char 
*device_path)
 
lock_chunks(root);
 
+   q = bdev_get_queue(bdev);
+   if (blk_queue_discard(q))
+   device-can_discard = 1;
device-writeable = 1;
device-work.func = pending_bios_fn;
generate_random_uuid(device-uuid);
@@ -1646,6 +1661,8 @@ int btrfs_init_new_device(struct btrfs_root *root, char 
*device_path)
root-fs_info-fs_devices-num_devices++;
root-fs_info-fs_devices-open_devices++;
root-fs_info-fs_devices-rw_devices++;
+   if (device-can_discard)
+   root-fs_info-fs_devices-num_can_discard++;

[PATCH] Btrfs: calculate checksum space correctly

2011-08-04 Thread Josef Bacik

We have not been reserving enough space for checksums.  We were just reserving
bytes for the checksum items themselves, we were not taking into account having
to cow the tree and such.  This patch adds a csum_bytes counter to the inode for
keeping track of the number of bytes outstanding we have for checksums.  Then we
calculate how many leaves would be required for the checksums we are given and
use that to reserve space.  This adds a significant amount of bytes to our
reservations, but we will handle this later.  Thanks,

Signed-off-by: Josef Bacik jo...@redhat.com
---
 fs/btrfs/btrfs_inode.h |6 +++
 fs/btrfs/extent-tree.c |  117 ---
 fs/btrfs/inode.c   |3 +
 3 files changed, 118 insertions(+), 8 deletions(-)

diff --git a/fs/btrfs/btrfs_inode.h b/fs/btrfs/btrfs_inode.h
index 5e9a7a7..559da62 100644
--- a/fs/btrfs/btrfs_inode.h
+++ b/fs/btrfs/btrfs_inode.h
@@ -123,6 +123,12 @@ struct btrfs_inode {
 */
u64 last_unlink_trans;
 
+   /*
+* Number of bytes outstanding that are going to need csums.  This is
+* used in ENOSPC accounting.
+*/
+   u64 csum_bytes;
+
/* flags field from the on disk inode */
u32 flags;
 
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 6928d19..fc4a800 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -3979,11 +3979,19 @@ int btrfs_snap_reserve_metadata(struct 
btrfs_trans_handle *trans,
return block_rsv_migrate_bytes(src_rsv, dst_rsv, num_bytes);
 }
 
+/**
+ * drop_outstanding_extent - drop an outstanding extent
+ * @inode: the inode we're dropping the extent for
+ *
+ * This is called when we are freeing up an outstanding extent, either called
+ * after an error or after an extent is written.  This will return the number 
of
+ * reserved extents that need to be freed.  This must be called with
+ * BTRFS_I(inode)-lock held.
+ */
 static unsigned drop_outstanding_extent(struct inode *inode)
 {
unsigned dropped_extents = 0;
 
-   spin_lock(BTRFS_I(inode)-lock);
BUG_ON(!BTRFS_I(inode)-outstanding_extents);
BTRFS_I(inode)-outstanding_extents--;
 
@@ -3993,19 +4001,70 @@ static unsigned drop_outstanding_extent(struct inode 
*inode)
 */
if (BTRFS_I(inode)-outstanding_extents =
BTRFS_I(inode)-reserved_extents)
-   goto out;
+   return 0;
 
dropped_extents = BTRFS_I(inode)-reserved_extents -
BTRFS_I(inode)-outstanding_extents;
BTRFS_I(inode)-reserved_extents -= dropped_extents;
-out:
-   spin_unlock(BTRFS_I(inode)-lock);
return dropped_extents;
 }
 
-static u64 calc_csum_metadata_size(struct inode *inode, u64 num_bytes)
+/**
+ * calc_csum_metadata_size - return the amount of metada space that must be
+ * reserved/free'd for the given bytes.
+ * @inode: the inode we're manipulating
+ * @num_bytes: the number of bytes in question
+ * @reserve: 1 if we are reserving space, 0 if we are freeing space
+ *
+ * This adjusts the number of csum_bytes in the inode and then returns the
+ * correct amount of metadata that must either be reserved or freed.  We
+ * calculate how many checksums we can fit into one leaf and then divide the
+ * number of bytes that will need to be checksumed by this value to figure out
+ * how many checksums will be required.  If we are adding bytes then the number
+ * may go up and we will return the number of additional bytes that must be
+ * reserved.  If it is going down we will return the number of bytes that must
+ * be freed.
+ *
+ * This must be called with BTRFS_I(inode)-lock held.
+ */
+static u64 calc_csum_metadata_size(struct inode *inode, u64 num_bytes,
+  int reserve)
 {
-   return num_bytes = 3;
+   struct btrfs_root *root = BTRFS_I(inode)-root;
+   u64 csum_size;
+   int num_csums_per_leaf;
+   int num_csums;
+   int old_csums;
+
+   if (BTRFS_I(inode)-flags  BTRFS_INODE_NODATASUM 
+   BTRFS_I(inode)-csum_bytes == 0)
+   return 0;
+
+   old_csums = (int)div64_u64(BTRFS_I(inode)-csum_bytes, 
root-sectorsize);
+   if (reserve)
+   BTRFS_I(inode)-csum_bytes += num_bytes;
+   else
+   BTRFS_I(inode)-csum_bytes -= num_bytes;
+   csum_size = BTRFS_LEAF_DATA_SIZE(root) - sizeof(struct btrfs_item);
+   num_csums_per_leaf = (int)div64_u64(csum_size,
+   sizeof(struct btrfs_csum_item) +
+   sizeof(struct btrfs_disk_key));
+   num_csums = (int)div64_u64(BTRFS_I(inode)-csum_bytes, 
root-sectorsize);
+   num_csums = num_csums + num_csums_per_leaf - 1;
+   num_csums = num_csums / num_csums_per_leaf;
+
+   old_csums = old_csums + num_csums_per_leaf - 1;
+   old_csums = old_csums / num_csums_per_leaf;
+
+   /* No change, no need to reserve more */
+   if

Re: Slow snapshot deletion

2011-08-04 Thread Bruce Guenter

On Thu, Jul 28, 2011 at 04:51:24PM -0400, Chris Mason wrote:
 Sorry, hit send too soon.  Here is the latencytop patch, after you
 recompile run latencytop -c for a few minutes.  Send the output here.
 
 http://oss.oracle.com/~mason/latencytop.patch

Ok, I ran it for more than a few minutes.  Early on (shortly after boot), the 
output shows this for a long time:

=== Mon Aug  1 21:09:30 2011
Globals: Cause Maximum Percentage
Process details:
Process ksoftirqd/0 (3) Total:   3.9 msec
[run_ksoftirqd]   3.9 msec100.0 %
run_ksoftirqd kthread kernel_thread_helper 
Process kworker/1:1 (983) Total:  31.2 msec
. 3.9 msec100.0 %
worker_thread kthread kernel_thread_helper 
Process sshd (3948) Total:   3.9 msec
Waiting for event (select)3.9 msec100.0 %
poll_schedule_timeout do_select core_sys_select sys_select 
system_call_fastpath 
Process btrfs-cleaner (4345) Total: 2433.6 msec
[sleep_on_page]  31.3 msec100.0 %
sleep_on_page wait_on_page_bit read_extent_buffer_pages 
btree_read_extent_buffer_pages read_tree_block 
read_block_for_search btrfs_search_slot 
lookup_inline_extent_backref __btrfs_free_extent 
run_clustered_refs btrfs_run_delayed_refs 
__btrfs_end_transaction 
Process btrfs-transacti (4346) Total: 2437.5 msec
[sleep_on_page]  27.3 msec100.0 %
sleep_on_page wait_on_page_bit read_extent_buffer_pages 
btree_read_extent_buffer_pages read_tree_block 
read_block_for_search btrfs_search_slot 
lookup_inline_extent_backref __btrfs_free_extent 
run_clustered_refs btrfs_run_delayed_refs 
btrfs_commit_transaction 

This repeats identically (all numbers and backtrace is very stable) for
a long time.  Much later, I see this:

=== Tue Aug  2 13:46:29 2011
Globals: Cause Maximum Percentage
Process details:
Process btrfs-submit-0 (4332) Total: 199.2 msec
Creating block layer request 58.6 msec100.0 %
get_request_wait __make_request generic_make_request 
submit_bio run_scheduled_bios pending_bios_fn worker_loop 
kthread kernel_thread_helper 
Process btrfs-cleaner (4345) Total:   3.9 msec
Creating block layer request  3.9 msec100.0 %
get_request_wait __make_request generic_make_request 
submit_bio btrfs_map_bio btree_submit_bio_hook submit_one_bio 
read_extent_buffer_pages readahead_tree_block reada_walk_down 
do_walk_down walk_down_tree 
Process btrfs-endio-met (4700) Total:  35.2 msec
[worker_loop] 3.9 msec100.0 %
worker_loop kthread kernel_thread_helper 
Process kworker/1:2 (26315) Total:  50.8 msec
. 3.9 msec100.0 %
worker_thread kthread kernel_thread_helper 
[...snip...]
=== Thu Aug  4 12:34:08 2011
Globals: Cause Maximum Percentage
Process details:
Process btrfs-submit-0 (4332) Total: 199.2 msec
Creating block layer request 58.6 msec100.0 %
get_request_wait __make_request generic_make_request 
submit_bio run_scheduled_bios pending_bios_fn worker_loop 
kthread kernel_thread_helper 
Process btrfs-cleaner (4345) Total:   3.9 msec
Creating block layer request  3.9 msec100.0 %
get_request_wait __make_request generic_make_request 
submit_bio btrfs_map_bio btree_submit_bio_hook submit_one_bio 
read_extent_buffer_pages readahead_tree_block reada_walk_down 
do_walk_down walk_down_tree 
Process btrfs-endio-met (4700) Total:  35.2 msec
[worker_loop] 3.9 msec100.0 %
worker_loop kthread kernel_thread_helper 


-- 
Bruce Guenter br...@untroubled.orghttp://untroubled.org/


pgpHNcAr9dedT.pgp
Description: PGP signature

Re: Hot rb_next, setup_cluster_no_bitmap

2011-08-04 Thread Simon Kirby

On Thu, Aug 04, 2011 at 10:04:29AM -0400, Chris Mason wrote:

 Excerpts from Simon Kirby's message of 2011-08-03 21:32:10 -0400:
  Perhaps as a further clue as to what is going on, on this same backup box
  after all of the rsyncs are finished/killed and a good amount of time has
  passed (no cleaner processes running in the background or anything),
  sync is still consistently takes ~4 minutes to run, and pushes out a
  lot to disk every time it is run. Example:
  
  echo 3  /proc/sys/vm/drop_caches
  sync
  echo 3  /proc/sys/vm/drop_caches
  sync
  vmstat 1 
  time sync
 
 Just to confirm, the profiling during this time shows your system time
 is all in rb_next?

Correct, rb_next() called from setup_cluster_no_bitmap(). Also, much of the
other CPU time is spent spinning (on refill_lock, I think).

It's in this state again now (just one overnight backup run does it). It
doesn't seem to happen for the first few hours, but shows up by the next
morning.

Simon-
--
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

Re: INSTALL hint: create device btrfs-control

On Thu, Aug 04, 2011 at 12:10:00PM +0200, Helmut Hullen wrote:
 Hallo,
 
 you should please add a hint in
 
.../git/mason/btrfs-progs-unstable.git
 
 in the file INSTALL with at least the contents (please excuse my  
 gerlish)
 
 btrfs needs the device btrfs-control. Perhaps you have to create it:
 
 mknod /dev/btrfs-control c 10 234

   This should probably go in the problems FAQ [1] on the wiki
instead, since (a) it's really a problem with your distribution, and
(b) probably quite rare now that the majority of people are running
distributions with udev.

   What are the symptoms of not having the device node? (i.e. how
would I diagnose this particular problem?)

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
  --- What part of gestalt don't you understand? ---   


signature.asc
Description: Digital signature

[GIT PULL] Btrfs patches for scrub, backref walking and raid repair

2011-08-04 Thread Jan Schmidt

Hi Chris,

as you requested, you can pull my latest patches from

git://git.jan-o-sch.net/btrfs-unstable

You'll find three branches to choose from: scrub, containing the backref
walking code and patches to fixup nodatasum errors. They have been sent to the
mailing list lately as [PATCH v8 0/8] Btrfs scrub: print path to corrupted
files and trigger nodatasum fixup.

Next, there is a raid1-repair branch, adding code to write back good data as
we get it to failed disks in a raid setup. This was sent to the list as
[RFC PATCH 0/4] btrfs: Suggestion for raid auto-repair earlier. I added a
missing unlock (pointed out by Ian Kent), which should be the only difference
from the previous patch set.

Andi Kleen has looked over the raid1-repair series and suggested adding some
threshold to avoid flooding the console with errors from the repair attempts,
in case the drive is really bad. This is definitely important, but we can also
add them later (that's my opinion, at least). I'm planning to do more tests with
sata fault injectors. I should get some within the next days, hopefully. I'd
like to see the impact of flooding, which will make it easier to come with a
good solution for it.

The combination of both branches mentioned is the for-chris branch. It has the
scrub patches first, followed by the raid1-repair patches as contained in the
separate branches. The last commit in this branch is an integration commit,
improving nodatasum fixup for a corner case (detailed description is in the
commit message).
   
Thanks,
-Jan

Jan Schmidt (13):
  btrfs: added helper functions to iterate backrefs
  btrfs scrub: added unverified_errors
  btrfs scrub: print paths of corrupted files
  btrfs scrub: bugfix: mirror_num off by one
  btrfs: add mirror_num to extent_read_full_page
  btrfs scrub: use int for mirror_num, not u64
  btrfs scrub: add fixup code for errors on nodatasum files
  btrfs: new ioctls to do logical-inode and inode-path resolving
  btrfs: btrfs_multi_bio replaced with btrfs_bio
  btrfs: Do not use bio-bi_bdev after submission
  btrfs: Put mirror_num in bi_bdev
  btrfs: Moved repair code from inode.c to extent_io.c
  btrfs: integrating raid-repair and scrub-fixup-nodatasum

 fs/btrfs/Makefile  |3 +-
 fs/btrfs/backref.c |  764 
 fs/btrfs/backref.h |   62 
 fs/btrfs/disk-io.c |2 +-
 fs/btrfs/extent-tree.c |   10 +-
 fs/btrfs/extent_io.c   |  393 -
 fs/btrfs/extent_io.h   |   13 +-
 fs/btrfs/inode.c   |  157 +--
 fs/btrfs/ioctl.c   |  143 +
 fs/btrfs/ioctl.h   |   30 ++
 fs/btrfs/scrub.c   |  476 +++---
 fs/btrfs/volumes.c |  130 +
 fs/btrfs/volumes.h |   10 +-
 13 files changed, 1916 insertions(+), 277 deletions(-)
 create mode 100644 fs/btrfs/backref.c
 create mode 100644 fs/btrfs/backref.h

-- 
1.7.3.4

--
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

Re: Btrfs Slowdown (due to Memory Handling?)

Excerpts from Mitch Harder's message of 2011-08-04 14:40:20 -0400:
 On Thu, Aug 4, 2011 at 10:05 AM, Chris Mason chris.ma...@oracle.com wrote:
 
  Ok, so I'm going to guess that your problem is really with either file
  layout or just us using more metadata pages than the others.  The file
  layout part is easy to test, just replace your git repo with a fresh
  clone (or completely repack it).
 
  Sorry, I should have said replace your git repo with a fresh,
  non-hardlinked clone.  git clone by default will just make hardlinks if
  it can, so it has to be a fresh clone.
 
  -chris
 
 
 Oops, sorry, I let my responses slip off the list.
 
 You are right about there being a potentially huge difference between
 a cloned git repo and it's parent.  I didn't realize it could make
 such a difference.
 
 This problem now appears to have nothing to do with btrfs.  I can
 replicate the problem on an ext4 partition also if I use a copy of the
 parent git repository instead of a clone.  The problem seems to lie in
 the fragmentation of the git repository.
 
 If I work with a clone of my linux-btrfs repository, subsequent clones
 are much faster.  Cloning my parent linux-btrfs repo takes about 90
 minutes (when I have restricted free RAM).  Cloning a clone of the
 parent drops down to less than 10 minutes.
 
 With there being several other threads relating to btrfs 'slow downs',
 I though this issue might be related.

Great, glad to hear turned out to be filesystem agnostic.

The original git file format was basically very filesystem unfriendly
and it tends to fragment very badly. 

Linus' solution to this is the pack file format, which is space
efficient and very fast to access.  The only downside is that you need
to repack the repo from time to time or performance tends to fall off a
cliff.

There is a git-pack command and a git gc command that you can use to
restructure things, both making it smaller and much faster.

-chris
--
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

Re: [PATCH V3] Btrfs-progs: add btrfs subvolume get-default subcommand

2011-08-04 Thread David Sterba

Hi,

please move the help text for 'get-default' right after 'set-default',
it's logical and currently it's very easy to miss it (it took me a few
seconds to locate it event if I knew it's there :)

thanks,
david

On Tue, Jul 12, 2011 at 10:48:37AM +0800, Zhong, Xin wrote:
 diff --git a/btrfs.c b/btrfs.c
 index 67d6f6f..1af8360 100644
 --- a/btrfs.c
 +++ b/btrfs.c
@@ -78,6 +78,9 @@ static struct Command commands[] = {
as default.,
  NULL
},
 + { do_get_default_subvol, 1, subvolume get-default, path\n
 + Get the default subvolume of a filesystem.
 + },
{ do_find_newer, 2, subvolume find-new, path last_gen\n
List the recently modified files in a filesystem.,
  NULL
 diff --git a/btrfs_cmds.c b/btrfs_cmds.c
 ...
--
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

[PATCH] Btrfs: kill the orphan space calculation for snapshots

2011-08-04 Thread Josef Bacik

This patch kills off the calculation for the amount of space needed for the
orphan operations during a snapshot.  The thing is we only do snapshots on
commit, so any space that is in the block_rsv-freed[] isn't going to be in the
new snapshot anyway, so there isn't any reason to require that space to be
reserved for the snapshot to occur.  Thanks,

Signed-off-by: Josef Bacik jo...@redhat.com
---
 fs/btrfs/ctree.h   |5 ---
 fs/btrfs/inode.c   |   83 
 fs/btrfs/transaction.c |2 -
 3 files changed, 0 insertions(+), 90 deletions(-)

diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index f8fc34d..358d16b 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -2577,11 +2577,6 @@ int btrfs_update_inode(struct btrfs_trans_handle *trans,
 int btrfs_orphan_add(struct btrfs_trans_handle *trans, struct inode *inode);
 int btrfs_orphan_del(struct btrfs_trans_handle *trans, struct inode *inode);
 int btrfs_orphan_cleanup(struct btrfs_root *root);
-void btrfs_orphan_pre_snapshot(struct btrfs_trans_handle *trans,
-   struct btrfs_pending_snapshot *pending,
-   u64 *bytes_to_reserve);
-void btrfs_orphan_post_snapshot(struct btrfs_trans_handle *trans,
-   struct btrfs_pending_snapshot *pending);
 void btrfs_orphan_commit_root(struct btrfs_trans_handle *trans,
  struct btrfs_root *root);
 int btrfs_cont_expand(struct inode *inode, loff_t oldsize, loff_t size);
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 30c430f..4c8342f 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -2077,89 +2077,6 @@ void btrfs_run_delayed_iputs(struct btrfs_root *root)
up_read(root-fs_info-cleanup_work_sem);
 }
 
-/*
- * calculate extra metadata reservation when snapshotting a subvolume
- * contains orphan files.
- */
-void btrfs_orphan_pre_snapshot(struct btrfs_trans_handle *trans,
-   struct btrfs_pending_snapshot *pending,
-   u64 *bytes_to_reserve)
-{
-   struct btrfs_root *root;
-   struct btrfs_block_rsv *block_rsv;
-   u64 num_bytes;
-   int index;
-
-   root = pending-root;
-   if (!root-orphan_block_rsv || list_empty(root-orphan_list))
-   return;
-
-   block_rsv = root-orphan_block_rsv;
-
-   /* orphan block reservation for the snapshot */
-   num_bytes = block_rsv-size;
-
-   /*
-* after the snapshot is created, COWing tree blocks may use more
-* space than it frees. So we should make sure there is enough
-* reserved space.
-*/
-   index = trans-transid  0x1;
-   if (block_rsv-reserved + block_rsv-freed[index]  block_rsv-size) {
-   num_bytes += block_rsv-size -
-(block_rsv-reserved + block_rsv-freed[index]);
-   }
-
-   *bytes_to_reserve += num_bytes;
-}
-
-void btrfs_orphan_post_snapshot(struct btrfs_trans_handle *trans,
-   struct btrfs_pending_snapshot *pending)
-{
-   struct btrfs_root *root = pending-root;
-   struct btrfs_root *snap = pending-snap;
-   struct btrfs_block_rsv *block_rsv;
-   u64 num_bytes;
-   int index;
-   int ret;
-
-   if (!root-orphan_block_rsv || list_empty(root-orphan_list))
-   return;
-
-   /* refill source subvolume's orphan block reservation */
-   block_rsv = root-orphan_block_rsv;
-   index = trans-transid  0x1;
-   if (block_rsv-reserved + block_rsv-freed[index]  block_rsv-size) {
-   num_bytes = block_rsv-size -
-   (block_rsv-reserved + block_rsv-freed[index]);
-   ret = btrfs_block_rsv_migrate(pending-block_rsv,
- root-orphan_block_rsv,
- num_bytes);
-   BUG_ON(ret);
-   }
-
-   /* setup orphan block reservation for the snapshot */
-   block_rsv = btrfs_alloc_block_rsv(snap);
-   BUG_ON(!block_rsv);
-
-   btrfs_add_durable_block_rsv(root-fs_info, block_rsv);
-   snap-orphan_block_rsv = block_rsv;
-
-   num_bytes = root-orphan_block_rsv-size;
-   ret = btrfs_block_rsv_migrate(pending-block_rsv,
- block_rsv, num_bytes);
-   BUG_ON(ret);
-
-#if 0
-   /* insert orphan item for the snapshot */
-   WARN_ON(!root-orphan_item_inserted);
-   ret = btrfs_insert_orphan_item(trans, root-fs_info-tree_root,
-  snap-root_key.objectid);
-   BUG_ON(ret);
-   snap-orphan_item_inserted = 1;
-#endif
-}
-
 enum btrfs_orphan_cleanup_state {
ORPHAN_CLEANUP_STARTED  = 1,
ORPHAN_CLEANUP_DONE = 2,
diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
index eb55863..7b3991b 100644
--- a/fs/btrfs/transaction.c
+++ b/fs/btrfs/transaction.c
@@ -923,7 +923,6 @@

Re: INSTALL hint: create device btrfs-control

Hallo, Hugo,

Du meintest am 04.08.11:

What are the symptoms of not having the device node? (i.e. how
 would I diagnose this particular problem?)

The days get shorter and shorter ...

running

btrfs device scan

produces something like

...
failed to read /dev/hdc
failed to read /dev/hdc8
failed to read /dev/lmscd
failed to read /dev/sdc1
failed to read /dev/sdb4
failed to open /dev/btrfs-control skipping device registration
failed to read /dev/sdd8
failed to read /dev/hdc9
failed to read /dev/sdf8
...

a lot of error messages for not existing devices and 1 error messages on  
behalf of btrfs-control.

My /dev directory has worked (without udev) without any problem for  
more than 10 years, it contains (has contained) a lot of entries for  
nearly every case of disk. Therefore i had started with

btrfs device scan 2/dev/null

and that deleted the btrfs-control error message too. And

btrfs device scan 21 | grep -v 'failed to'

didn't help too.


btrfs-show

doesn't need /dev/btrfs-control, it shows the existing btrfs  
partition(s).

If I remember correct: mounting works, writing works, reading works. And  
adding another partition works.

But there are strange messages when I try to resize or delete.

I'll try to reproduce these messages ...

Viele Gruesse!
Helmut
--
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

Re: [PATCH] Btrfs: detect wether a device supports discard

Excerpts from David Sterba's message of 2011-08-04 16:00:54 -0400:
 just for the record: this issue has been reported and a patch is
 awaiting inclusion:
 
 https://patchwork.kernel.org/patch/791822/ (report  discussion)
 https://patchwork.kernel.org/patch/915502/ (last update)

Right, Josef's patch adds a small incremental fix over those.  I'm
sending them in with the pile of bug fixes for rc2.

-chris
--
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

Re: INSTALL hint: create device btrfs-control

On Thu, Aug 04, 2011 at 10:13:00PM +0200, Helmut Hullen wrote:
Hallo, Hugo,

Du meintest am 04.08.11:

What are the symptoms of not having the device node? (i.e. how
would I diagnose this particular problem?)

The days get shorter and shorter ...

running

btrfs device scan

produces something like

...
failed to read /dev/hdc
failed to read /dev/hdc8
failed to read /dev/lmscd
failed to read /dev/sdc1
failed to read /dev/sdb4
failed to open /dev/btrfs-control skipping device registration

OK, that's the symptom we can put in the problems list for this
particular issue.

failed to read /dev/sdd8
failed to read /dev/hdc9
failed to read /dev/sdf8
...

a lot of error messages for not existing devices and 1 error messages on
behalf of btrfs-control.

My /dev directory has worked (without udev) without any problem for
more than 10 years, it contains (has contained) a lot of entries for
nearly every case of disk. Therefore i had started with

btrfs device scan 2/dev/null

and that deleted the btrfs-control error message too. And

btrfs device scan 21 | grep -v 'failed to'

didn't help too.

Goffredo published a patch to scan only the contents of
/proc/partitions, which should at least shut up the scan over the
issue of non-existent devices in /dev. That's in the next
integration-* branch (going out shortly... I'm just integrating and
updating the balance management patches before i release).

btrfs-show

doesn't need /dev/btrfs-control, it shows the existing btrfs
partition(s).

If I remember correct: mounting works, writing works, reading works. And
adding another partition works.

But there are strange messages when I try to resize or delete.

I'll try to reproduce these messages ...

Thanks. We can add those as symptoms to the solution later.

How's this?

https://btrfs.wiki.kernel.org/index.php/Problem_FAQ#I_get_the_message_.22failed_to_open_.2Fdev.2Fbtrfs-control_skipping_device_registration.22_from_.22btrfs_dev_scan.22

Hugo.

--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- I lost my leg in 1942. Some bastard stole it in a ---
pub in Pimlico.

signature.asc
Description: Digital signature

Re: INSTALL hint: create device btrfs-control

   Hi, Helmut,

On Thu, Aug 04, 2011 at 11:26:00PM +0200, Helmut Hullen wrote:
 Du meintest am 04.08.11:
  I'll try to reproduce these messages ...
 
 Thanks. We can add those as symptoms to the solution later.
 
 I've just run the first test - finding reliable (for only this case)  
 messages is a bad job ...

   Well, it's probably OK just to use this particular symptom for
now. You've generally got to run btrfs dev scan before you run
anything else, so that message should turn up. I wouldn't spend ages
hunting down additional failure messages.

 How's this?
 
  https://btrfs.wiki.kernel.org/index.php/Problem_FAQ#I_get_the_message
  _.22failed_to_open_.2Fdev.2Fbtrfs-control_skipping_device_registratio
  n.22_from_.22btrfs_dev_scan.22
 
 There's some problem in the Wiki. This new paragraph (?) is not shown  
 when I call the Problem_FAQ, it ends with the Copy-on-write doesn't  
 work question.
 
 When I look into the source code of that page I can see and read the  
 paragraph, and it looks fine!

   Yes, I think there is a problem with it at the moment. The usual
one that happens every so often. I don't know what's up, but it seems
to be something to do with the MySQL back-end.

   At least the text looks good to you, so we'll leave it at that for
now, and it should be better the next time the kernel.org admins sort
it out.

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
  --- What's so bad about being drunk? You ask a glass of water ---  
 


signature.asc
Description: Digital signature

btrfs-progs integration branch updated

   All - 

   It's been a while, but I've finally managed to get the time to
re-work the integration branch, and it's up as integration-20110805 at
darksatanic.net:

http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ integration-20110805

   It includes the latest scrub patches, the compile fixes for gcc
4.6, and a selection of other, smaller features. Go forth and play.

   Please let me know if I've got any outstanding patches that went to
the list that I've not picked up yet (there's one I know of, I'm
following that up in just a moment).

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
   --- Strive for apathy! ---


signature.asc
Description: Digital signature

[GIT PULL] btrfs-progs

   Hi, Chris,

   I've finally reworked the integration branch, and integrated what
should be a good version of the scrub userspace. You can pull it from:

http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ for-chris

   Hugo.

Andreas Philipp (10):
  Added support for an additional ioctl.
  Add support for read-only subvolumes.
  Support the new parameters in do_clone(int argc, char** argv).
  Test the additional ioctl.
  Updated manpage for btrfs subvolume snapshot.
  add all targets to clean target
  some style/layout changes
  print parent ID in btrfs suvolume list
  update manpage entries for btrfs subvolume list
  remove unused include version.h

Anton Blanchard (1):
  btrfs-progs: cast u64 to long long to avoid printf warnings

Arne Jansen (3):
  btrfs-map-logical: usage update
  btrfs progs: fix extra metadata chunk allocation in --mixed case
  btrfs-map-logical: segfaults when no output file is given

Chris Ball (1):
  Fix unused-but-set errors in gcc-4.6

Fajar A. Nugraha (1):
  make btrfs filesystem label command actually work

Hubert Kario (3):
  add advanced use of --help to help message
  add detailed help messages to btrfs command
  remove unused variables

Hugo Mills (4):
  btrfs-progs: Fix over-sized limit on buffer
  mkfs.btrfs: Fix compilation errors with gcc 4.6
  gcc 4.6: fix potentially unused variable
  fix incorrect argument checking for btrfs sub snap -r

Jan Schmidt (6):
  mkfs should initialize unused fields properly
  btrfs-progs: commands added
  btrfs-progs: scrub ioctls
  btrfs-progs: added check_mounted_where
  btrfs-progs: scrub userland implementation
  btrfs-progs: scrub added to manpage

Kamble, Nitin A (1):
  make btrfs cross compilation friendly

Sergei Trofimovich (8):
  btrfs-convert: fix typo: 'all inode' - 'all inodes'
  mkfs.btrfs: fail on scandir error (-r mode)
  mkfs.btrfs: return some defined value instead of garbage when lookup 
checksum
  mkfs.btrfs: fix symlink names writing
  mkfs.btrfs: write zeroes instead on uninitialized data.
  mkfs.btrfs: free buffers allocated by pretty_sizes
  mkfs.btrfs: fix memory leak caused by 'scandir()' calls
  mkfs.btrfs: fix error text in '-r' mode

Stephane Chazelas (1):
  incorrect argument checking for btrfs sub snap -r

Tsutomu Itoh (1):
  btrfs-progs: setting of time to the root directory

cwillu (1):
  Btrfs-progs: Correct path munging in bcp

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
   --- Strive for apathy! ---


signature.asc
Description: Digital signature

Re: [GIT PULL] btrfs-progs

On Fri, Aug 05, 2011 at 12:00:04AM +0100, Hugo Mills wrote:
Hi, Chris,
 
I've finally reworked the integration branch, and integrated what
 should be a good version of the scrub userspace. You can pull it from:
 
 http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ for-chris

   Oops, I forgot to mention -- it's against the tmp branch of your
repo.

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
   --- Strive for apathy! ---


signature.asc
Description: Digital signature

device delete: more informations

Hallo,

I've made a 2-partitions system with

mkfs.btrfs -P Probe -m raid1 -d raid0 /dev/sdb1

mount LABEL=Probe /mnt/Probe

btrfs device add /dev/sdb2 /mnt/Probe

btrfs-show (and other tests) showed that all worked well.

btrfs device delete /dev/sdb2 /mnt/Probe

only showed error (I haven't noticed the long text, something like  
can't delete); but dmesg showed the reason:

  btrfs: unable to go below two devices on raid1

Could this message also shown in the regular error message?

Viele Gruesse!
Helmut
--
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

Re: INSTALL hint: create device btrfs-control