Re: Balance RAID10 with odd device count
Le 21 February 2012 ? 07:54, Hugo Mills a écrit: Some time ago, I proposed the following scheme: nCmSpP where n is the number of copies (suffixed by C), m is the number of stripes for that data (suffixed by S), and p is the number of parity blocks (suffixed by P). Values of zero are omitted. So btrfs's RAID-1 would be 2C, RAID-0 would be 1CnS, RAID-5 would be 1CnS1P, and RAID-6 would be 1CnS2P. DUP would need a special indicator to show that it wasn't redundant in the face of a whole-disk failure: 2CN Seems clear. However, is the S really relevant ? It would be simpler without it, wouldn't it ? -- Xavier Nicollet -- 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: Balance RAID10 with odd device count
On Wed, Feb 22, 2012 at 11:22:08AM +0100, Hubert Kario wrote: On Wednesday 22 of February 2012 09:56:27 Xavier Nicollet wrote: Le 21 February 2012 ? 07:54, Hugo Mills a écrit: Some time ago, I proposed the following scheme: nCmSpP where n is the number of copies (suffixed by C), m is the number of stripes for that data (suffixed by S), and p is the number of parity blocks (suffixed by P). Values of zero are omitted. So btrfs's RAID-1 would be 2C, RAID-0 would be 1CnS, RAID-5 would be 1CnS1P, and RAID-6 would be 1CnS2P. DUP would need a special indicator to show that it wasn't redundant in the face of a whole-disk failure: 2CN Seems clear. However, is the S really relevant ? It would be simpler without it, wouldn't it ? It depends how striping will be implemented. Generally it provides information on how much spindles is the data using. With static configuration it will be useless, but when you start changing number of drives in set then it's necessary to know if you're not under- or over- utilising the disks. Indeed. If the implementation always uses the largest number of devices possible, then we'll always have nS. If it allows you to set a fixed number of devices for a stripe, then the n will be a fixed number, and it becomes useful. 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 --- Happiness is mandatory. Are you happy? --- signature.asc Description: Digital signature
Re: brtfs on top of dmcrypt with SSD. No corruption iff write cache off?
On 15/02/12 17:59, Hugo Mills wrote: It's a temporary location (6 months and counting) while kernel.org is static-pages-only. Hugo. Couldn't btrfs.wiki.kernel.org be made a CNAME for btrfs.ipv5.de for the time being until kernel.org is up and running? Or alternatively all requests could be proxied/frame-forwarded/redirected (in order of preference, to make sure everybody keeps using the original url as much as possible) to btrfs.ipv5.de? Kernel.org is a complex site and I can easily foresee them having to spent months still fixing/hardening all of it's internals and backends before getting around to these extra project facilities. Regards, justin -- 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: Balance RAID10 with odd device count
Hugo Mills posted on Tue, 21 Feb 2012 01:21:48 + as excerpted: On Mon, Feb 20, 2012 at 08:13:43PM -0500, Tom Cameron wrote: On Mon, Feb 20, 2012 at 8:07 PM, Hugo Mills h...@carfax.org.uk wrote: However, you can remove any one drive, and your data is fine, which is what btrfs's RAID-1 guarantee is. I understand that there will be additional features coming along Real Soon Now (possibly at the same time that RAID-5 and -6 are integrated) which will allow the selection of larger numbers of copies. Is there a projected timeframe for RAID5/6? I understand it's currently not the development focus of the BTRFS team, and most organizations want performance over capacity making RAID10 the clear choice. But, there are still some situations where RAID6 is better suited (large pools of archive storage). Rumour has it that it's the next major thing after btrfsck is out of the door. I don't know how accurate that is. I'm just some bloke on the Internet. :) The report I read (on phoronix, ymmv but it was supposed to be from a talk at scalex, iirc) said raid-5/6 was planned for kernel 3.4 or 3.5, with triple-copy-mirroring said to piggyback on some of that code, so presumably 3.5 or 3.6. Triple-copy-mirroring as a special case doesn't really make sense to me, tho. The first implementation as two-copy (dup) only makes sense, but in generalizing that to allow triple copy, I'd think/hope they'd generalize it to N-copy, IOW, traditional raid-1 style, instead. I guess we'll see. FWIW, I'm running on an older 4-spindle md-raid1 setup now, and I had /hoped/ to convert that to 4-copy btrfs-raid1, but that's simply not possible ATM tho a hybrid 2-copy btrfs on dual dual-spindle md/raid1s is possible, if a bit complex. Given that the disks are older, 300 gig sata seagates nearing half their rated run-hours according to smart (great on power and spinup cycles tho), now's not the time to switch them to dual-copy-only! I'd think about triple-copy, but no less! Thus, I'm eagerly awaiting the introduction of tri- or preferably N-copy raid1 mode, in 3.5-ish. But the various articles had lead me to believe that btrfs was almost ready to have the experimental label removed, and it turns out not to be quite that far along, maybe end-of-year if things go well, so letting btrfs continue to stabilize in general while I wait, certainly won't hurt. =:^) Meanwhile, I'm staying on-list so as to keep informed of what else is going on, btrfs-wise, while I wait for triple-copy-mode, minimum. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- 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-progs: man: fix typo
s/eveery/every/ Signed-off-by: Andrea Gelmini andrea.gelm...@gelma.net --- man/btrfs.8.in |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/man/btrfs.8.in b/man/btrfs.8.in index 8e3b2f5..e2792c9 100644 --- a/man/btrfs.8.in +++ b/man/btrfs.8.in @@ -137,7 +137,7 @@ is similar to \fBsubvolume list\fR command. Defragment file data and/or directory metadata. To defragment all files in a directory you have to specify each one on its own or use your shell wildcards. -The start position and the number of bytes to deframention can be specified by \fIstart\fR and \fIlen\fR. Any extent bigger than \fIthresh\fR will be considered already defragged. Use 0 to take the kernel default, and use 1 to say eveery single extent must be rewritten. You can also turn on compression in defragment operations. +The start position and the number of bytes to deframention can be specified by \fIstart\fR and \fIlen\fR. Any extent bigger than \fIthresh\fR will be considered already defragged. Use 0 to take the kernel default, and use 1 to say every single extent must be rewritten. You can also turn on compression in defragment operations. \fB-v\fP be verbose -- 1.7.9.1.275.gd59d2 -- 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: Is there any data recovery tool?
qasdfgtyuiop posted on Tue, 21 Feb 2012 20:11:06 +0800 as excerpted: I'm using GNU/linux with btrfs root. My filesystem is created with command mkfs.btrfs /dev/sda . Today I'm trying to install Microsoft Windows 7 on /dev/sdb , a 16GB esata ssd. After the installation, I found that Windows create a hidden NTFS partition called System Reserved on the first 100MB of my /dev/sda and that my btrfs filesystem was lost! I have searched google for help but I got no useful information. Is there any data recovery tools? The btrfs kernel option says: Btrfs filesystem (EXPERIMENTAL) Unstable disk format Its description says in part: Btrfs is highly experimental, and THE DISK FORMAT IS NOT YET FINALIZED. You should say N here unless you are interested in testing Btrfs with non- critical data. [...] If unsure, say N. The front page and getting started pages of the wiki (see URL below) also heavily emphasize the development aspect and backups, and the source code section has this to say: Warning, Btrfs evolves very quickly do not test it unless: You have good backups and you have tested the restore capability You have a backup installation that you can switch to when something breaks You are willing to report any issues you find You can apply patches and compile the latest btrfs code against your kernel (quite easy with git and dkms, see below) You acknowledge that btrfs may eat your data Backups! Backups! Backups! Given all that, any data you store on btrfs is by definition not particularly important, either because you have it backed up in a more stable format elsewhere (which might be the net, or local), or because the data really /isn't/ particularly important to you in the first place, or you'd have made and tested backups (naturally, always test recovery from your backups, as an untested backup is worse than none, since it's likely to give you a false sense of security) before putting it on the after all still experimental and under heavy development btrfs in the first place. Thus, you shouldn't need to worry about a data recovery tool, since you can either simply restore from backups (which since you tested recovery, you're already familiar with the recovery procedures), or the data was simply garbage you were using for testing and didn't care about losing anyway. Never-the-less, yes, there's a recovery tool, naturally experimental just like the filesystem itself at this point, but there is one. Testing and suggestions for improvements, especially with patches, will be welcomed. It seems you need to read up on the wiki, which covers this among other things. There's an older version on btrfs.wiki.kernel.org, but that's not updated ATM due to restrictions in place since the kernel.org breakin some months ago. The temporary (but six months and counting, I believe) replacement is at btrfs.ipv5.de: http://btrfs.ipv5.de/index.php?title=Main_Page The restore and find-root commands from btrfs-progs are specifically covered on this page: http://btrfs.ipv5.de/index.php?title=Restore If you wish to try a newer copy of btrfs-progs (after all, it's all still in development, and bugs are fixed all the time), you'll also want to read: http://btrfs.ipv5.de/index.php?title=Getting_started#Compiling_Btrfs_from_sources -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- 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: silence a compiler warning
On Wed, Feb 22, 2012 at 10:30:55AM +0300, Dan Carpenter wrote:
Gcc warns that ret can be used uninitialized. It can't actually be
used uninitialized because btrfs_num_copies() always returns 1 or more.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/fs/btrfs/check-integrity.c b/fs/btrfs/check-integrity.c
index 064b29b..c053e90 100644
--- a/fs/btrfs/check-integrity.c
+++ b/fs/btrfs/check-integrity.c
@@ -643,7 +643,7 @@ static struct btrfsic_dev_state
*btrfsic_dev_state_hashtable_lookup(
static int btrfsic_process_superblock(struct btrfsic_state *state,
struct btrfs_fs_devices *fs_devices)
{
- int ret;
+ int ret = 0;
Does
int uninitialized_var(ret);
work? The assignment to zero actually generates additional
(unnecessary) code.
David
--
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
[weird] High CPU usage caused by btrfs-transaction thread busy doing find_next_zero_bit()
Dear devs, My filesystem is super-sluggish since about a week, and perf top tells me that find_next_bit(), find_next_zero_bit() is eating my netbook's CPU. The kernel is 3.3-rc3+188 (g3ec1e88) and I don't use this laptop a lot, so I'm ready to cooperate. In the btrfs-transaction thread, in descending order of CPU usage: find_next_zero_bit, find_next_bit, rb_next, setup_cluster_bitmap, setup_cluster_no_bitmap, tree_search_offset. I'm on #btrfs (Zougloub) Regards, -- cJ -- 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: silence a compiler warning
On Wed, Feb 22, 2012 at 08:29:26AM -0800, David Brown wrote:
On Wed, Feb 22, 2012 at 10:30:55AM +0300, Dan Carpenter wrote:
Gcc warns that ret can be used uninitialized. It can't actually be
used uninitialized because btrfs_num_copies() always returns 1 or more.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/fs/btrfs/check-integrity.c b/fs/btrfs/check-integrity.c
index 064b29b..c053e90 100644
--- a/fs/btrfs/check-integrity.c
+++ b/fs/btrfs/check-integrity.c
@@ -643,7 +643,7 @@ static struct btrfsic_dev_state
*btrfsic_dev_state_hashtable_lookup(
static int btrfsic_process_superblock(struct btrfsic_state *state,
struct btrfs_fs_devices *fs_devices)
{
-int ret;
+int ret = 0;
Does
int uninitialized_var(ret);
work? The assignment to zero actually generates additional
(unnecessary) code.
Sure. I can resend it.
regards,
dan carpenter
signature.asc
Description: Digital signature
Re: btrfs-convert processing time
So, the btrfs-convert for the smaller drive is done... after near 5 days. Which stats can I give you ? It's a 340GB LVM block device, and btrfs filesystem df /backup/ say that : Data: total=225.97GB, used=181.94GB System: total=32.00MB, used=24.00KB Metadata: total=111.00GB, used=91.56GB If I mount the ext2_saved/image copy, I can see 257GB of data (78% of the block device used), with 17M of inodes. The other btrfs-convert stay running. -- 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
Btrfs filesystem resize syntax
What happened to the patches to --help and man pages that did explain the multi-device use-case: btrfs filesystem resize [devid:][+/-]newsize[gkm]|max filesystem (the devid: bit is missing) It is explained on the wiki: http://btrfs.ipv5.de/index.php?title=Btrfs(command) but I don't see those patches in Chris btrfs-progs tree. Regards, -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawerów 30/85 tel. +48 (22) 646-61-51, 646-74-24 www.qbs.com.pl -- 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: clear the extent uptodate bits during parent transid failures
Normally I just toss patches into git, but this one is pretty subtle and
I wanted to send it around for extra review. QA at Oracle did a test
where they unplugged one drive of a btrfs raid1 mirror for a while and
then plugged it back in.
The end result is that we have a whole bunch of out-of-date blocks on
the bad mirror. The btrfs parent transid pointers are supposed to
detect these bad blocks and then we're supposed to read from the good
copy instead.
The good news is we did detect the bad blocks. The bad news is we
didn't jump over to the good mirror instead. This patch explains why:
Author: Chris Mason chris.ma...@oracle.com
Date: Wed Feb 22 12:36:24 2012 -0500
Btrfs: clear the extent uptodate bits during parent transid failures
If btrfs reads a block and finds a parent transid mismatch, it clears
the uptodate flags on the extent buffer, and the pages inside it. But
we only clear the uptodate bits in the state tree if the block straddles
more than one page.
This is from an old optimization from to reduce contention on the extent
state tree. But it is buggy because the code that retries a read from
a different copy of the block is going to find the uptodate state bits
set and skip the IO.
The end result of the bug is that we'll never actually read the good
copy (if there is one).
The fix here is to always clear the uptodate state bits, which is safe
because this code is only called when the parent transid fails.
Signed-off-by: Chris Mason chris.ma...@oracle.com
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 1e8d5e5..a4dc892 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -3852,10 +3852,9 @@ int clear_extent_buffer_uptodate(struct extent_io_tree
*tree,
num_pages = num_extent_pages(eb-start, eb-len);
clear_bit(EXTENT_BUFFER_UPTODATE, eb-bflags);
- if (eb_straddles_pages(eb)) {
- clear_extent_uptodate(tree, eb-start, eb-start + eb-len - 1,
- cached_state, GFP_NOFS);
- }
+ clear_extent_uptodate(tree, eb-start, eb-start + eb-len - 1,
+ cached_state, GFP_NOFS);
+
for (i = 0; i num_pages; i++) {
page = extent_buffer_page(eb, i);
if (page)
--
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 v2] Btrfs: silence a compiler warning
Gcc warns that ret can be used uninitialized. It can't actually be
used uninitialized because btrfs_num_copies() always returns 1 or more.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
v2: use the uninitialized_var() macro instead of initializing to 0.
diff --git a/fs/btrfs/check-integrity.c b/fs/btrfs/check-integrity.c
index 064b29b..3bb3853 100644
--- a/fs/btrfs/check-integrity.c
+++ b/fs/btrfs/check-integrity.c
@@ -643,7 +643,7 @@ static struct btrfsic_dev_state
*btrfsic_dev_state_hashtable_lookup(
static int btrfsic_process_superblock(struct btrfsic_state *state,
struct btrfs_fs_devices *fs_devices)
{
- int ret;
+ int uninitialized_var(ret);
struct btrfs_super_block *selected_super;
struct list_head *dev_head = fs_devices-devices;
struct btrfs_device *device;
signature.asc
Description: Digital signature
3.3 restripe between different raid levels
[Referring to https://lkml.org/lkml/2012/1/17/381], and perhaps I'm a bit previous, but what are the command sequence to change the raid levels? Wouldn't mind being pointed to git manual if better for you. Well done and thank you to all involved. -- 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: 3.3 restripe between different raid levels
Alex alex at bpmit.com writes: The closing square bracket got caught up in the URL: sb https://lkml.org/lkml/2012/1/17/381 -- 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: clear the extent uptodate bits during parent transid failures
On 02/23/2012 01:43 AM, Chris Mason wrote:
Normally I just toss patches into git, but this one is pretty subtle and
I wanted to send it around for extra review. QA at Oracle did a test
where they unplugged one drive of a btrfs raid1 mirror for a while and
then plugged it back in.
The end result is that we have a whole bunch of out-of-date blocks on
the bad mirror. The btrfs parent transid pointers are supposed to
detect these bad blocks and then we're supposed to read from the good
copy instead.
The good news is we did detect the bad blocks. The bad news is we
didn't jump over to the good mirror instead. This patch explains why:
Author: Chris Mason chris.ma...@oracle.com
Date: Wed Feb 22 12:36:24 2012 -0500
Btrfs: clear the extent uptodate bits during parent transid failures
If btrfs reads a block and finds a parent transid mismatch, it clears
the uptodate flags on the extent buffer, and the pages inside it. But
we only clear the uptodate bits in the state tree if the block straddles
more than one page.
This is from an old optimization from to reduce contention on the extent
state tree. But it is buggy because the code that retries a read from
a different copy of the block is going to find the uptodate state bits
set and skip the IO.
The end result of the bug is that we'll never actually read the good
copy (if there is one).
The fix here is to always clear the uptodate state bits, which is safe
because this code is only called when the parent transid fails.
Reviewed-by: Liu Bo liubo2...@cn.fujitsu.com
or we can be safer:
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index fcf77e1..c1fe25d 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -3859,8 +3859,12 @@ int clear_extent_buffer_uptodate(struct extent_io_tree
*tree,
}
for (i = 0; i num_pages; i++) {
page = extent_buffer_page(eb, i);
- if (page)
+ if (page) {
+ u64 start = (u64)page-index PAGE_CACHE_SHIFT;
+ u64 end = start + PAGE_CACHE_SIZE - 1;
+
ClearPageUptodate(page);
+ clear_extent_uptodate(tree, start, end, NULL, GFP_NOFS);
}
return 0;
}
Signed-off-by: Chris Mason chris.ma...@oracle.com
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 1e8d5e5..a4dc892 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -3852,10 +3852,9 @@ int clear_extent_buffer_uptodate(struct extent_io_tree
*tree,
num_pages = num_extent_pages(eb-start, eb-len);
clear_bit(EXTENT_BUFFER_UPTODATE, eb-bflags);
- if (eb_straddles_pages(eb)) {
- clear_extent_uptodate(tree, eb-start, eb-start + eb-len - 1,
- cached_state, GFP_NOFS);
- }
+ clear_extent_uptodate(tree, eb-start, eb-start + eb-len - 1,
+ cached_state, GFP_NOFS);
+
for (i = 0; i num_pages; i++) {
page = extent_buffer_page(eb, i);
if (page)
--
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
--
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: fix error handling of btrfs_iget()
btrfs_iget() never return NULL. So, NULL check is unnecessary.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/relocation.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 8c1aae2..be1caf4 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -3240,8 +3240,8 @@ static int delete_block_group_cache(struct btrfs_fs_info
*fs_info,
key.offset = 0;
inode = btrfs_iget(fs_info-sb, key, root, NULL);
- if (IS_ERR_OR_NULL(inode) || is_bad_inode(inode)) {
- if (inode !IS_ERR(inode))
+ if (IS_ERR(inode) || is_bad_inode(inode)) {
+ if (!IS_ERR(inode))
iput(inode);
return -ENOENT;
}
--
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 1/3] Btrfs-progs, btrfs-map-logical: Fix typo in usage
The right option is 'o' not 'c'. And this tool is used for the block devices
on which there is a btrfs file system, so change mount_point to device.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
btrfs-map-logical.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/btrfs-map-logical.c b/btrfs-map-logical.c
index d79a73a..fa4fb3f 100644
--- a/btrfs-map-logical.c
+++ b/btrfs-map-logical.c
@@ -84,7 +84,7 @@ struct extent_buffer *debug_read_block(struct btrfs_root
*root, u64 bytenr,
static void print_usage(void)
{
- fprintf(stderr, usage: btrfs-map-logical [options] mount_point\n);
+ fprintf(stderr, usage: btrfs-map-logical [options] device\n);
fprintf(stderr, \t-l Logical extent to map\n);
fprintf(stderr, \t-c Copy of the extent to read (usually 1 or 2)\n);
fprintf(stderr, \t-o Output file to hold the extent\n);
@@ -96,7 +96,7 @@ static struct option long_options[] = {
/* { byte-count, 1, NULL, 'b' }, */
{ logical, 1, NULL, 'l' },
{ copy, 1, NULL, 'c' },
- { output, 1, NULL, 'c' },
+ { output, 1, NULL, 'o' },
{ bytes, 1, NULL, 'b' },
{ 0, 0, 0, 0}
};
--
1.7.6.5
--
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 2/3] Btrfs-progs, btrfs-corrupt-block: fix the wrong usage
The old usage is a copy of btrfs-map-logical, it's wrong, fix it.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
This patch is against dangerdonteveruse branch.
---
btrfs-corrupt-block.c | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/btrfs-corrupt-block.c b/btrfs-corrupt-block.c
index 9ad3e05..df84c81 100644
--- a/btrfs-corrupt-block.c
+++ b/btrfs-corrupt-block.c
@@ -85,11 +85,13 @@ struct extent_buffer *debug_corrupt_block(struct btrfs_root
*root, u64 bytenr,
static void print_usage(void)
{
- fprintf(stderr, usage: btrfs-map-logical [options] mount_point\n);
- fprintf(stderr, \t-l Logical extent to map\n);
- fprintf(stderr, \t-c Copy of the extent to read (usually 1 or 2)\n);
- fprintf(stderr, \t-o Output file to hold the extent\n);
- fprintf(stderr, \t-b Number of bytes to read\n);
+ fprintf(stderr, usage: btrfs-corrupt-block [options] device\n);
+ fprintf(stderr, \t-l Logical extent to be corrupted\n);
+ fprintf(stderr, \t-c Copy of the extent to be corrupted
+(usually 1 or 2, default: 0)\n);
+ fprintf(stderr, \t-b Number of bytes to be corrupted\n);
+ fprintf(stderr, \t-e Extent to be corrupted\n);
+ fprintf(stderr, \t-E The whole extent free to be corrupted\n);
exit(1);
}
@@ -244,7 +246,7 @@ int main(int ac, char **av)
while(1) {
int c;
- c = getopt_long(ac, av, l:c:eE, long_options,
+ c = getopt_long(ac, av, l:c:b:eE, long_options,
option_index);
if (c 0)
break;
--
1.7.6.5
--
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 3/3] Btrfs-progs: fix btrfsck's snapshot wrong unresolved refs
If the fs/file tree is not the parent of the snapshot, it is reasonable
that we can not find the relative reference and back reference. But btrfsck
doesn't consider this case, and reports unresolved refs message, it's wrong,
fix it.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
btrfsck.c | 72
1 files changed, 67 insertions(+), 5 deletions(-)
diff --git a/btrfsck.c b/btrfsck.c
index 1935dd7..a8a8211 100644
--- a/btrfsck.c
+++ b/btrfsck.c
@@ -745,7 +745,65 @@ static int leave_shared_node(struct btrfs_root *root,
return 0;
}
-static int process_dir_item(struct extent_buffer *eb,
+static int is_child_root(struct btrfs_root *root, u64 parent_root_id,
+u64 child_root_id)
+{
+ struct btrfs_path path;
+ struct btrfs_key key;
+ struct extent_buffer *leaf;
+ int has_parent = 0;
+ int ret;
+
+ btrfs_init_path(path);
+
+ key.objectid = parent_root_id;
+ key.type = BTRFS_ROOT_REF_KEY;
+ key.offset = child_root_id;
+ ret = btrfs_search_slot(NULL, root-fs_info-tree_root, key, path,
+ 0, 0);
+ BUG_ON(ret 0);
+ btrfs_release_path(root, path);
+ if (!ret)
+ return 1;
+
+ key.objectid = child_root_id;
+ key.type = BTRFS_ROOT_BACKREF_KEY;
+ key.offset = 0;
+ ret = btrfs_search_slot(NULL, root-fs_info-tree_root, key, path,
+ 0, 0);
+ BUG_ON(ret = 0);
+
+ while (1) {
+ leaf = path.nodes[0];
+ if (path.slots[0] = btrfs_header_nritems(leaf)) {
+ ret = btrfs_next_leaf(root-fs_info-tree_root, path);
+ BUG_ON(ret 0);
+
+ if (ret 0)
+ break;
+ }
+
+ btrfs_item_key_to_cpu(leaf, key, path.slots[0]);
+ if (key.objectid != child_root_id ||
+ key.type != BTRFS_ROOT_BACKREF_KEY)
+ break;
+
+ has_parent = 1;
+
+ if (key.offset == parent_root_id) {
+ btrfs_release_path(root, path);
+ return 1;
+ }
+
+ path.slots[0]++;
+ }
+
+ btrfs_release_path(root, path);
+ return has_parent? 0 : -1;
+}
+
+static int process_dir_item(struct btrfs_root *root,
+ struct extent_buffer *eb,
int slot, struct btrfs_key *key,
struct shared_node *active_node)
{
@@ -793,9 +851,13 @@ static int process_dir_item(struct extent_buffer *eb,
key-objectid, key-offset, namebuf,
len, filetype, key-type, error);
} else if (location.type == BTRFS_ROOT_ITEM_KEY) {
- add_inode_backref(root_cache, location.objectid,
- key-objectid, key-offset, namebuf,
- len, filetype, key-type, error);
+ u64 parent = root-objectid;
+
+ if (is_child_root(root, parent, location.objectid))
+ add_inode_backref(root_cache, location.objectid,
+ key-objectid, key-offset,
+ namebuf, len, filetype,
+ key-type, error);
} else {
fprintf(stderr, warning line %d\n, __LINE__);
}
@@ -1026,7 +1088,7 @@ static int process_one_leaf(struct btrfs_root *root,
struct extent_buffer *eb,
switch (key.type) {
case BTRFS_DIR_ITEM_KEY:
case BTRFS_DIR_INDEX_KEY:
- ret = process_dir_item(eb, i, key, active_node);
+ ret = process_dir_item(root, eb, i, key, active_node);
break;
case BTRFS_INODE_REF_KEY:
ret = process_inode_ref(eb, i, key, active_node);
--
1.7.6.5
--
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
