Re: Patches for BTRFS (mail-server slow down in 3.0 and more)
On Sat, Oct 29, 2011 at 02:35:16AM -0200, Alexandre Oliva wrote: > On Oct 28, 2011, Marcel Lohmann wrote: > > > I would really appreciate if you could send me the patches. > > Here are the patches I mentioned on IRC. I've sent two of them to Josef > for him to push upstream, but I'm not sure he posted them here for I'm > not on the list (yet?). The other two are newer, and the last one is > definitely not for inclusion (just for testing or as a temporary > work-around). The last one isn't a bad idea, but please do make a real mount option for it ;) -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 progs git repo on kernel.org
On Fri, Oct 28, 2011 at 07:27:56PM +0300, Sergei Trofimovich wrote: > > Hi everyone, > > > > I've pulled in Hugo's integration tree, minus the features that were not > > yet in the kernel. This also has a few small commits that I had queued > > up outside of the fsck work. > > > > Hugo, many thanks for keeping up the integration tree! Taking out the > > features not in the kernel meant I had to rebase it the commits, I'm > > sorry about that. > > > > The code from the integration tree is here: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git > > Sounds great! Should we treat is as new home of a thing called "-unstable" > before? > > > git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git > > Or you are planning to restore that repo as well? That's a good point, I'll see if I can make the -unstable a link. Still figuring out the new git interface. But yes, this is the new home of the progs. -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: Patches for BTRFS (mail-server slow down in 3.0 and more)
On Oct 28, 2011, Marcel Lohmann wrote:
> I would really appreciate if you could send me the patches.
Here are the patches I mentioned on IRC. I've sent two of them to Josef
for him to push upstream, but I'm not sure he posted them here for I'm
not on the list (yet?). The other two are newer, and the last one is
definitely not for inclusion (just for testing or as a temporary
work-around).
I've been using the first 3 with some success on a couple of mail
servers: I haven't hit the ridiculous slow downs from frequent
unsuccessful calls of setup_cluster_no_bitmap after a while, like I did
with 3.0 (and 3.1) any more.
However, the excess use of metadata that I've experienced on ceph OSDs
isn't fixed by them. A btrfs balance with the first 3 still has 22GB of
metadata block groups even though only 4.1GB of metadata are in use, or
19GB of metadata with only 2GB of metadata in use. With the 4th patch
and -o clear_cache, the first rebalancing of the 22GB-metadata
filesystem got it down to 8GB; the second fs is still on rebalancing
~800GB (wishlist mental note: introduce some means to rebalance only the
metadata)
Here are the patches, against 3.1-libre (should apply cleanly on 3.1).
--- Begin Message ---
Parameterized clusters on minimum total size and minimum chunk size,
without an upper bound. Don't tolerate fragmentation for SSD_SPREAD;
accept some fragmentation for metadata but try to keep data dense.
Signed-off-by: Alexandre Oliva
---
fs/btrfs/free-space-cache.c | 64 +++---
1 files changed, 35 insertions(+), 29 deletions(-)
diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
index 41ac927..4973816 100644
--- a/fs/btrfs/free-space-cache.c
+++ b/fs/btrfs/free-space-cache.c
@@ -2092,8 +2092,8 @@ static int btrfs_bitmap_cluster(struct
btrfs_block_group_cache *block_group,
struct btrfs_free_space_ctl *ctl = block_group->free_space_ctl;
unsigned long next_zero;
unsigned long i;
- unsigned long search_bits;
- unsigned long total_bits;
+ unsigned long want_bits;
+ unsigned long min_bits;
unsigned long found_bits;
unsigned long start = 0;
unsigned long total_found = 0;
@@ -2102,8 +2102,8 @@ static int btrfs_bitmap_cluster(struct
btrfs_block_group_cache *block_group,
i = offset_to_bit(entry->offset, block_group->sectorsize,
max_t(u64, offset, entry->offset));
- search_bits = bytes_to_bits(bytes, block_group->sectorsize);
- total_bits = bytes_to_bits(min_bytes, block_group->sectorsize);
+ want_bits = bytes_to_bits(bytes, block_group->sectorsize);
+ min_bits = bytes_to_bits(min_bytes, block_group->sectorsize);
again:
found_bits = 0;
@@ -2112,7 +2112,7 @@ again:
i = find_next_bit(entry->bitmap, BITS_PER_BITMAP, i + 1)) {
next_zero = find_next_zero_bit(entry->bitmap,
BITS_PER_BITMAP, i);
- if (next_zero - i >= search_bits) {
+ if (next_zero - i >= min_bits) {
found_bits = next_zero - i;
break;
}
@@ -2132,9 +2132,9 @@ again:
if (cluster->max_size < found_bits * block_group->sectorsize)
cluster->max_size = found_bits * block_group->sectorsize;
- if (total_found < total_bits) {
+ if (total_found < want_bits) {
i = find_next_bit(entry->bitmap, BITS_PER_BITMAP, next_zero);
- if (i - start > total_bits * 2) {
+ if (i - start > want_bits * 2) {
total_found = 0;
cluster->max_size = 0;
found = false;
@@ -2180,8 +2180,8 @@ setup_cluster_no_bitmap(struct btrfs_block_group_cache
*block_group,
* We don't want bitmaps, so just move along until we find a normal
* extent entry.
*/
- while (entry->bitmap) {
- if (list_empty(&entry->list))
+ while (entry->bitmap || entry->bytes < min_bytes) {
+ if (entry->bitmap && list_empty(&entry->list))
list_add_tail(&entry->list, bitmaps);
node = rb_next(&entry->offset_index);
if (!node)
@@ -2196,10 +2196,8 @@ setup_cluster_no_bitmap(struct btrfs_block_group_cache
*block_group,
last = entry;
prev = entry;
- while (window_free <= min_bytes) {
- node = rb_next(&entry->offset_index);
- if (!node)
- return -ENOSPC;
+ for (node = rb_next(&entry->offset_index); node;
+node = rb_next(&entry->offset_index)) {
entry = rb_entry(node, struct btrfs_free_space, offset_index);
if (entry->bitmap) {
@@ -2208,12 +2206,19 @@ setup_cluster_no_bitmap(struct btrfs_block_group_cache
*block_group,
continue;
Re: Unable to mount btrfs partition
On Fri, 28 Oct 2011 22:09:47 +0100, Hugo Mills wrote: On Fri, Oct 28, 2011 at 08:36:28PM +, em...@joachim-neu.de wrote: Today I downgraded from Ubuntu's APT repo "oneiric-proposed" (which brings some kernel 3.0.0-13) back to the standard repo "oneiric". It's odd that switching from one 3.0.0 to another would cause something bad to happen. Did something else happen in the process, like a reboot without a clean shutdown? (This includes power loss, suspend and failure to resume, and Alt-SysRq-b). I agree, but there was no power loss or anything. Maybe the fs didn't unmount correctly or fast enough when rebooting? Now I'm not able to mount my btrfs / and /home (both on the same partition) anymore: device fsid SOME-UUID devid 1 transid 84229 /dev/dm-0 parent transid verify failed on 77078528 wanted 83774 found 84226 parent transid verify failed on 77078528 wanted 83774 found 84226 parent transid verify failed on 77078528 wanted 83774 found 84226 parent transid verify failed on 77078528 wanted 83774 found 84226 btrfs: open_ctree failed The boot process drops to the initramfs shell with no btrfsck available. It wouldn't make any difference if it were -- btrfsck doesn't actually fix anything, I'm afraid. This error message is regrettably generic, and covers a whole range of evils. It's possible that 3.1 may be able to deal swith the breakage ufficiently well to allow you to boot and copy your files. I'll give the 3.1 kernel a try right after "restore" finished which is running right now and doing quite a good job so far (as far as my / is concerned, lets wait for the /home). What do the above error messages indicate? Is there an incrementing number for every transaction and the number of the most recent transaction is stored somewhere and those messages occur once those numbers are out of sync somehow? Is it possible to "just" discard the last transactions? I would not mind, better loose a day than a month... Why is the message there three times? Is this information stored in a couple of backups? If so: can't I use any of the other backups temporarily? "restore" opens the fs in a ro recovery mode somehow where it ignores those errors. Is it possible to "force" the btrfs driver to load the fs in this recovery mode as readonly, too? I tried to boot with both the "new" 3.0.0-13 kernel and the old 3.0.0-12 and 3.0.0-11 kernels -- no success. I'm running a live cd right now with 3.0.0-12 and I get the above error no matter what I do: no mount, no fsck, no nothing. I really hope someone can help me get my data back... You could try using a 3.1 kernel, as I suggested above. Failing that, in josef's git repository at [1], you will find a tool called "restore". This should allow you to copy any files that had been modified since your last backup. If you haven't got backups, you *really* should look into getting some before continuing to use a filesystem marked as EXPERIMENTAL... Hugo. Thanks a lot for your help so far. I hope "restore" will do the trick, if not I'll give kernel 3.1 a try. Joachim [1] https://github.com/josefbacik/btrfs-progs -- 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: Unable to mount btrfs partition
On Fri, Oct 28, 2011 at 08:36:28PM +, em...@joachim-neu.de wrote: > Today I downgraded from Ubuntu's APT repo "oneiric-proposed" (which > brings some kernel 3.0.0-13) back to the standard repo "oneiric". It's odd that switching from one 3.0.0 to another would cause something bad to happen. Did something else happen in the process, like a reboot without a clean shutdown? (This includes power loss, suspend and failure to resume, and Alt-SysRq-b). > Now I'm not able to mount my btrfs / and /home (both on the same > partition) anymore: > > device fsid SOME-UUID devid 1 transid 84229 /dev/dm-0 > parent transid verify failed on 77078528 wanted 83774 found 84226 > parent transid verify failed on 77078528 wanted 83774 found 84226 > parent transid verify failed on 77078528 wanted 83774 found 84226 > parent transid verify failed on 77078528 wanted 83774 found 84226 > btrfs: open_ctree failed > > The boot process drops to the initramfs shell with no btrfsck > available. It wouldn't make any difference if it were -- btrfsck doesn't actually fix anything, I'm afraid. This error message is regrettably generic, and covers a whole range of evils. It's possible that 3.1 may be able to deal swith the breakage ufficiently well to allow you to boot and copy your files. > I tried to boot with both the "new" 3.0.0-13 kernel and > the old 3.0.0-12 and 3.0.0-11 kernels -- no success. I'm running a > live cd right now with 3.0.0-12 and I get the above error no matter > what I do: no mount, no fsck, no nothing. > > I really hope someone can help me get my data back... You could try using a 3.1 kernel, as I suggested above. Failing that, in josef's git repository at [1], you will find a tool called "restore". This should allow you to copy any files that had been modified since your last backup. If you haven't got backups, you *really* should look into getting some before continuing to use a filesystem marked as EXPERIMENTAL... Hugo. [1] https://github.com/josefbacik/btrfs-progs -- === 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 --- If you're not part of the solution, you're part --- of the precipiate. signature.asc Description: Digital signature
Unable to mount btrfs partition
Hello! Today I downgraded from Ubuntu's APT repo "oneiric-proposed" (which brings some kernel 3.0.0-13) back to the standard repo "oneiric". Now I'm not able to mount my btrfs / and /home (both on the same partition) anymore: device fsid SOME-UUID devid 1 transid 84229 /dev/dm-0 parent transid verify failed on 77078528 wanted 83774 found 84226 parent transid verify failed on 77078528 wanted 83774 found 84226 parent transid verify failed on 77078528 wanted 83774 found 84226 parent transid verify failed on 77078528 wanted 83774 found 84226 btrfs: open_ctree failed The boot process drops to the initramfs shell with no btrfsck available. I tried to boot with both the "new" 3.0.0-13 kernel and the old 3.0.0-12 and 3.0.0-11 kernels -- no success. I'm running a live cd right now with 3.0.0-12 and I get the above error no matter what I do: no mount, no fsck, no nothing. I really hope someone can help me get my data back... Joachim -- 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 3/5] mm: try to distribute dirty pages fairly across zones
[restore CC list] > > I'm trying to understand where the performance gain comes from. > > > > I noticed that in all cases, before/after patchset, nr_vmscan_write are all > > zero. > > > > nr_vmscan_immediate_reclaim is significantly reduced though: > > That's a good thing, it means we burn less CPU time on skipping > through dirty pages on the LRU. > > Until a certain priority level, the dirty pages encountered on the LRU > list are marked PageReclaim and put back on the list, this is the > nr_vmscan_immediate_reclaim number. And only below that priority, we > actually ask the FS to write them, which is nr_vmscan_write. Yes, it is. > I suspect this is where the performance improvement comes from: we > find clean pages for reclaim much faster. That explains how it could reduce CPU overheads. However the dd's are throttled anyway, so I still don't understand how the speedup of dd page allocations improve the _IO_ performance. > > $ ./compare.rb -g 1000M -e nr_vmscan_immediate_reclaim > > thresh*/*-ioless-full-nfs-wq5-next-20111014+ > > thresh*/*-ioless-full-per-zone-dirty-next-20111014+ > > 3.1.0-rc9-ioless-full-nfs-wq5-next-20111014+ > > 3.1.0-rc9-ioless-full-per-zone-dirty-next-20111014+ > > > >560289.00 -98.5% 8145.00 > > thresh=1000M/btrfs-100dd-4k-8p-4096M-1000M:10-X > >576882.00 -98.4% 9511.00 > > thresh=1000M/btrfs-10dd-4k-8p-4096M-1000M:10-X > >651258.00 -98.8% 7963.00 > > thresh=1000M/btrfs-1dd-4k-8p-4096M-1000M:10-X > > 1963294.00 -85.4%286815.00 > > thresh=1000M/ext3-100dd-4k-8p-4096M-1000M:10-X > > 2108028.00 -10.6% 1885114.00 > > thresh=1000M/ext3-10dd-4k-8p-4096M-1000M:10-X > > 2499456.00 -99.9% 2061.00 > > thresh=1000M/ext3-1dd-4k-8p-4096M-1000M:10-X > > 2534868.00 -78.5%545815.00 > > thresh=1000M/ext4-100dd-4k-8p-4096M-1000M:10-X > > 2921668.00 -76.8%677177.00 > > thresh=1000M/ext4-10dd-4k-8p-4096M-1000M:10-X > > 2841049.00 -100.0% 779.00 > > thresh=1000M/ext4-1dd-4k-8p-4096M-1000M:10-X > > 2481823.00 -86.3%339342.00 > > thresh=1000M/xfs-100dd-4k-8p-4096M-1000M:10-X > > 2508629.00 -87.4%316614.00 > > thresh=1000M/xfs-10dd-4k-8p-4096M-1000M:10-X > > 2656628.00 -100.0% 678.00 > > thresh=1000M/xfs-1dd-4k-8p-4096M-1000M:10-X > > 24303872.00 -83.2% 4080014.00 TOTAL > > nr_vmscan_immediate_reclaim > > > > If you'd like to compare any other vmstat items before/after patch, > > let me know and I'll run the compare script to find them out. > > I will come back to you on this, so tired right now. But I find your > scripts interesting ;-) Are those released and available for download > somewhere? I suspect every kernel hacker has their own collection of > scripts to process data like this, maybe we should pull them all > together and put them into a git tree! Thank you for the interest :-) I used to upload my writeback test scripts to kernel.org. However its file service is not restored yet. So I attach the compare script here. It's a bit hacky for now, which I hope can be improved over time to be useful to other projects as well. Thanks, Fengguang compare.rb Description: application/ruby
Re: [patch 3/5] mm: try to distribute dirty pages fairly across zones
Hi Johannes, I tested this patchset over the IO-less dirty throttling one. The below numbers show that //improvements 1) write bandwidth increased by 1% in general 2) greatly reduced nr_vmscan_immediate_reclaim //regression 3) much increased cpu %user and %system for btrfs Thanks, Fengguang --- kernel before this patchset: 3.1.0-rc9-ioless-full-nfs-wq5-next-20111014+ kernel after this patchset: 3.1.0-rc9-ioless-full-per-zone-dirty-next-20111014+ 3.1.0-rc9-ioless-full-nfs-wq5-next-20111014+ 3.1.0-rc9-ioless-full-per-zone-dirty-next-20111014+ 2056.51+1.0% 2076.29 TOTAL write_bw 32260625.00 -86.0% 4532517.00 TOTAL nr_vmscan_immediate_reclaim 90.44 +25.7% 113.67 TOTAL cpu_user 113.05+9.9% 124.25 TOTAL cpu_system 3.1.0-rc9-ioless-full-nfs-wq5-next-20111014+ 3.1.0-rc9-ioless-full-per-zone-dirty-next-20111014+ 52.43+1.3%53.12 thresh=1000M/btrfs-100dd-4k-8p-4096M-1000M:10-X 52.72+0.8%53.16 thresh=1000M/btrfs-10dd-4k-8p-4096M-1000M:10-X 52.24+2.7%53.67 thresh=1000M/btrfs-1dd-4k-8p-4096M-1000M:10-X 35.52+1.2%35.94 thresh=1000M/ext3-100dd-4k-8p-4096M-1000M:10-X 39.37+1.6%39.98 thresh=1000M/ext3-10dd-4k-8p-4096M-1000M:10-X 47.52+0.5%47.75 thresh=1000M/ext3-1dd-4k-8p-4096M-1000M:10-X 47.13+1.1%47.64 thresh=1000M/ext4-100dd-4k-8p-4096M-1000M:10-X 52.28+3.0%53.86 thresh=1000M/ext4-10dd-4k-8p-4096M-1000M:10-X 54.34+1.0%54.87 thresh=1000M/ext4-1dd-4k-8p-4096M-1000M:10-X 47.63+0.3%47.78 thresh=1000M/xfs-100dd-4k-8p-4096M-1000M:10-X 51.25+2.1%52.34 thresh=1000M/xfs-10dd-4k-8p-4096M-1000M:10-X 52.66+2.5%54.00 thresh=1000M/xfs-1dd-4k-8p-4096M-1000M:10-X 54.63-0.0%54.63 thresh=100M/btrfs-10dd-4k-8p-4096M-100M:10-X 53.75+1.0%54.29 thresh=100M/btrfs-1dd-4k-8p-4096M-100M:10-X 54.14+0.4%54.35 thresh=100M/btrfs-2dd-4k-8p-4096M-100M:10-X 36.87-0.0%36.86 thresh=100M/ext3-10dd-4k-8p-4096M-100M:10-X 45.20-0.3%45.07 thresh=100M/ext3-1dd-4k-8p-4096M-100M:10-X 40.75-0.6%40.51 thresh=100M/ext3-2dd-4k-8p-4096M-100M:10-X 44.14+0.3%44.29 thresh=100M/ext4-10dd-4k-8p-4096M-100M:10-X 52.91+0.1%52.99 thresh=100M/ext4-1dd-4k-8p-4096M-100M:10-X 50.30+0.8%50.72 thresh=100M/ext4-2dd-4k-8p-4096M-100M:10-X 44.55+2.8%45.80 thresh=100M/xfs-10dd-4k-8p-4096M-100M:10-X 52.75+4.3%55.03 thresh=100M/xfs-1dd-4k-8p-4096M-100M:10-X 50.99+1.7%51.87 thresh=100M/xfs-2dd-4k-8p-4096M-100M:10-X 37.35+2.0%38.11 thresh=10M/btrfs-10dd-4k-8p-4096M-10M:10-X 53.32+2.3%54.55 thresh=10M/btrfs-1dd-4k-8p-4096M-10M:10-X 50.72+3.9%52.70 thresh=10M/btrfs-2dd-4k-8p-4096M-10M:10-X 32.05+0.7%32.27 thresh=10M/ext3-10dd-4k-8p-4096M-10M:10-X 43.91-1.2%43.39 thresh=10M/ext3-1dd-4k-8p-4096M-10M:10-X 42.37+0.3%42.50 thresh=10M/ext3-2dd-4k-8p-4096M-10M:10-X 35.04-1.9%34.36 thresh=10M/ext4-10dd-4k-8p-4096M-10M:10-X 52.93-0.4%52.73 thresh=10M/ext4-1dd-4k-8p-4096M-10M:10-X 49.24-0.0%49.22 thresh=10M/ext4-2dd-4k-8p-4096M-10M:10-X 30.96-0.8%30.73 thresh=10M/xfs-10dd-4k-8p-4096M-10M:10-X 54.30-0.8%53.89 thresh=10M/xfs-1dd-4k-8p-4096M-10M:10-X 45.63+1.2%46.17 thresh=10M/xfs-2dd-4k-8p-4096M-10M:10-X 1.92-1.5% 1.89 thresh=1M/btrfs-10dd-4k-8p-4096M-1M:10-X 2.28+5.9% 2.42 thresh=1M/btrfs-1dd-4k-8p-4096M-1M:10-X 2.07-1.4% 2.04 thresh=1M/btrfs-2dd-4
[PATCH] btrfs: Avoid creating new file in append-only dir when open(2) return error
Newly created file on btrfs inherits inode flags from parent directory,
so new inode created in append-only directory has S_APPEND flag set,
may_open() called by do_last() checks that flag then returns -EPERM,
but at that time the new inode is already created.
This can be reproduced by:
# mkdir -p /mnt/btrfs/append-only
# chattr +a /mnt/btrfs/append-only
# ./opentest /mnt/btrfs/append-only/newtestfile
# ls -l /mnt/btrfs/append-only/newtestfile
opentest will return 'Operation not permitted', but the ls shows that
newtestfile is already created.
# cat opentest.c
#include
#include
#include
#include
int main(int argc, char *argv[])
{
int fd;
fd = open(argv[1], O_RDWR|O_CREAT, 0666);
if (fd == -1)
perror("open failed");
return 0;
}
To avoid this, check BTRFS_INODE_APPEND flag first in btrfs_create before
really allocating new inode.
Cc: Chris Mason
Signed-off-by: Eryu Guan
---
fs/btrfs/inode.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index b2d004a..18e9914 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include "compat.h"
#include "ctree.h"
#include "disk-io.h"
@@ -4718,10 +4719,19 @@ static int btrfs_create(struct inode *dir, struct
dentry *dentry,
struct inode *inode = NULL;
int drop_inode = 0;
int err;
+ int open_flag = nd->intent.open.file->f_flags;
unsigned long nr = 0;
u64 objectid;
u64 index = 0;
+ if (BTRFS_I(dir)->flags & BTRFS_INODE_APPEND) {
+ if ((open_flag & O_ACCMODE) != O_RDONLY &&
+ !(open_flag & O_APPEND))
+ return -EPERM;
+ if (open_flag & O_TRUNC)
+ return -EPERM;
+ }
+
/*
* 2 for inode item and ref
* 2 for dir items
--
1.7.7.1
--
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: don't try to touch sb->s_bdev
Btrfs uses anon bdevs, this is not needed. Signed-off-by: Ilya Dryomov --- fs/btrfs/volumes.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index f2a4cc7..afd6a1e 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -1376,8 +1376,6 @@ int btrfs_rm_device(struct btrfs_root *root, char *device_path) next_device = list_entry(root->fs_info->fs_devices->devices.next, struct btrfs_device, dev_list); - if (device->bdev == root->fs_info->sb->s_bdev) - root->fs_info->sb->s_bdev = next_device->bdev; if (device->bdev == root->fs_info->fs_devices->latest_bdev) root->fs_info->fs_devices->latest_bdev = next_device->bdev; -- 1.7.6.3 -- 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 git repo on kernel.org
> Hi everyone, > > I've pulled in Hugo's integration tree, minus the features that were not > yet in the kernel. This also has a few small commits that I had queued > up outside of the fsck work. > > Hugo, many thanks for keeping up the integration tree! Taking out the > features not in the kernel meant I had to rebase it the commits, I'm > sorry about that. > > The code from the integration tree is here: > > git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git Sounds great! Should we treat is as new home of a thing called "-unstable" before? git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git Or you are planning to restore that repo as well? Thanks! -- Sergei signature.asc Description: PGP signature
Re: Unable to mount (or, why not to work late at night).
2011-10-28, 07:57(+07), Fajar A. Nugraha: [...] >> Already got 'em. Everything that tries to even think about modifying stuff >> (btrfs-zero-log, btrfsck, and btrfs-debug-tree) all dump core: > > Your last resort (for now, anyway) might be using "restore" from > Josef's btrfs-progs: https://github.com/josefbacik/btrfs-progs > > It might be able to copy some data. I also have got one FS in that same situation. I tried everything on it including that "restore" (which bailed out with those same error messages IIRC). The only thing that got me a bit further was to use an alternate superblock, though that screwed the FS even further as I need to reboot the machine after trying to mount it (mount hangs and there are some btrfs tasks using all the CPU time). Fortunately, for that one, I had a not too old backup at the block device level. -- Stephane -- 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 fi defrag -c
2011-10-28, 10:25(+08), Li Zefan: [...] > # df . -h > FilesystemSize Used Avail Use% Mounted on > /home/lizf/tmp/a 2.0G 409M 1.4G 23% /mnt OK, why are we not gaining space after compression though? > And I was not suprised, as there's a regression. > > With this fix: > > http://marc.info/?l=linux-btrfs&m=131495014823121&w=2 [...] Thanks. That's the one that's scheduled for 3.2 and maybe 3.1.x, right? -- Stephane -- 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
