Re: kernel BUG at /home/apw/COD/linux/fs/btrfs/extent_io.c:2116! when deleting device or balancing filesystem.
On Mon, Apr 28, 2014 at 03:26:45AM +, Duncan wrote: Jaap Pieroen posted on Sun, 27 Apr 2014 18:30:19 +0200 as excerpted: Hello, When I try to delete a device from my btrfs filesystem I always get the following kernel bug error: kernel BUG at /home/apw/COD/linux/fs/btrfs/extent_io.c:2116! invalid opcode: [#3] SMP See attached log file for more details. That's a reasonably common, generic error, simply indicating the kernel got an invalid/zero opcode instead of what it was supposed to get, but not really saying why, tho the log does give some more info. More than that -- the invalid opcode is simply the way that the BUG() and BUG_ON() macros are implemented. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- People are too unreliable to be replaced by machines. --- signature.asc Description: Digital signature
[PATCH 2/2] btrfs-progs: Replace the overkill assert with normal error message.
When 'btrfs replace status' encounters an unknown dev replace status, it
will cause an assert, which is somewhat overkilled and can be replaced
with a normal error message.
Signed-off-by: Qu Wenruo quwen...@cn.fujitsu.com
---
cmds-replace.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/cmds-replace.c b/cmds-replace.c
index 645dc98..9eb981b 100644
--- a/cmds-replace.c
+++ b/cmds-replace.c
@@ -449,7 +449,10 @@ static int print_replace_status(int fd, const char *path,
int once)
break;
default:
prevent_loop = 1;
- assert(0);
+ fprintf(stderr,
+ Unknown btrfs dev replace status:%llu,
+ status-replace_state);
+ ret = -EINVAL;
break;
}
@@ -459,9 +462,9 @@ static int print_replace_status(int fd, const char *path,
int once)
(unsigned long long)status-num_write_errors,
(unsigned long long)
status-num_uncorrectable_read_errors);
- if (once || prevent_loop) {
+ if (once || prevent_loop || ret) {
printf(\n);
- return 0;
+ return ret;
}
fflush(stdout);
--
1.9.2
--
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/2] btrfs-progs: Improve the errno string about open_path_or_dev_mnt()
open_path_or_dev_mnt() is used to on *mounted* btrfs device or mount
point, when a unmounted btrfs device is passed, errno is set to EINVAL to
info the caller.
If ignore the errno and just print ERROR: can't access '%s', end users
will get confused.
This patch will add check for open_path_or_dev_mnt() caller and print
more meaningful error message when a unmounted btrfs device path is
given.
Signed-off-by: Qu Wenruo quwen...@cn.fujitsu.com
---
cmds-device.c | 8 +++-
cmds-replace.c | 9 +++--
cmds-scrub.c | 25 +
3 files changed, 35 insertions(+), 7 deletions(-)
diff --git a/cmds-device.c b/cmds-device.c
index a9b4a38..f2e08ba 100644
--- a/cmds-device.c
+++ b/cmds-device.c
@@ -353,7 +353,13 @@ static int cmd_dev_stats(int argc, char **argv)
fdmnt = open_path_or_dev_mnt(dev_path, dirstream);
if (fdmnt 0) {
- fprintf(stderr, ERROR: can't access '%s'\n, dev_path);
+ if (errno == EINVAL)
+ fprintf(stderr,
+ ERROR: '%s' is not a mounted btrfs device\n,
+ dev_path);
+ else
+ fprintf(stderr, ERROR: can't access '%s': %s\n,
+ dev_path, strerror(errno));
return 1;
}
diff --git a/cmds-replace.c b/cmds-replace.c
index 01ab77c..645dc98 100644
--- a/cmds-replace.c
+++ b/cmds-replace.c
@@ -172,8 +172,13 @@ static int cmd_start_replace(int argc, char **argv)
fdmnt = open_path_or_dev_mnt(path, dirstream);
if (fdmnt 0) {
- fprintf(stderr, ERROR: can't access \%s\: %s\n,
- path, strerror(errno));
+ if (errno == EINVAL)
+ fprintf(stderr,
+ ERROR: '%s' is not a mounted btrfs device\n,
+ path);
+ else
+ fprintf(stderr, ERROR: can't access '%s': %s\n,
+ path, strerror(errno));
goto leave_with_error;
}
diff --git a/cmds-scrub.c b/cmds-scrub.c
index 4338a0b..616d797 100644
--- a/cmds-scrub.c
+++ b/cmds-scrub.c
@@ -1172,7 +1172,13 @@ static int scrub_start(int argc, char **argv, int resume)
fdmnt = open_path_or_dev_mnt(path, dirstream);
if (fdmnt 0) {
- ERR(!do_quiet, ERROR: can't access '%s'\n, path);
+ if (errno == EINVAL)
+ ERR(!do_quiet,
+ ERROR: '%s' is not a mounted btrfs device\n,
+ path);
+ else
+ ERR(!do_quiet, ERROR: can't access '%s': %s\n,
+ path, strerror(errno));
return 1;
}
@@ -1560,8 +1566,13 @@ static int cmd_scrub_cancel(int argc, char **argv)
fdmnt = open_path_or_dev_mnt(path, dirstream);
if (fdmnt 0) {
- fprintf(stderr, ERROR: could not open %s: %s\n,
- path, strerror(errno));
+ if (errno == EINVAL)
+ fprintf(stderr,
+ ERROR: '%s' is not a mounted btrfs device\n,
+ path);
+ else
+ fprintf(stderr, ERROR: can't access '%s': %s\n,
+ path, strerror(errno));
ret = 1;
goto out;
}
@@ -1658,7 +1669,13 @@ static int cmd_scrub_status(int argc, char **argv)
fdmnt = open_path_or_dev_mnt(path, dirstream);
if (fdmnt 0) {
- fprintf(stderr, ERROR: can't access '%s'\n, path);
+ if (errno == EINVAL)
+ fprintf(stderr,
+ ERROR: '%s' is not a mounted btrfs device\n,
+ path);
+ else
+ fprintf(stderr, ERROR: can't access '%s': %s\n,
+ path, strerror(errno));
return 1;
}
--
1.9.2
--
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: Confusing output of btrfs fi df
So try this one: btrfs balance start -musage=0 -v I fear that didn't work too. mars:/mnt # btrfs balance start -musage=0 -v btrfs/ Dumping filters: flags 0x6, state 0x0, force is off METADATA (flags 0x2): balancing, usage=0 SYSTEM (flags 0x2): balancing, usage=0 Done, had to relocate 1 out of 2708 chunks mars:/mnt # btrfs fi df btrfs/ Data, RAID1: total=2.64TiB, used=2.22TiB System, RAID1: total=8.00MiB, used=380.00KiB System, single: total=4.00MiB, used=0.00 Metadata, RAID1: total=4.00GiB, used=2.94GiB If that fails to remove the extra system chunk, then we have a mystery indeed. What's different on your system and why isn't it working? I have no idea. Its just a plain openSUSE 13.1 and they consider btrfs support stable enough to use it as default filesystem in the upcoming 13.2. I could create the filesystem again and restore the data but of course I would actually need to know what went wrong the first time in order to avoid doing it again. Is there anything you need to know about my system which would be of use? (Controller, Disks, Mainboard etc. ?) Yours sincerely Stefan -- 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: Confusing output of btrfs fi df
On Mon, Apr 28, 2014 at 01:57:02PM +0200, Stefan Malte Schumacher wrote: So try this one: btrfs balance start -musage=0 -v I fear that didn't work too. mars:/mnt # btrfs balance start -musage=0 -v btrfs/ Dumping filters: flags 0x6, state 0x0, force is off METADATA (flags 0x2): balancing, usage=0 SYSTEM (flags 0x2): balancing, usage=0 Done, had to relocate 1 out of 2708 chunks mars:/mnt # btrfs fi df btrfs/ Data, RAID1: total=2.64TiB, used=2.22TiB System, RAID1: total=8.00MiB, used=380.00KiB System, single: total=4.00MiB, used=0.00 Metadata, RAID1: total=4.00GiB, used=2.94GiB If that fails to remove the extra system chunk, then we have a mystery indeed. What's different on your system and why isn't it working? I have no idea. Its just a plain openSUSE 13.1 and they consider btrfs support stable enough to use it as default filesystem in the upcoming 13.2. I could create the filesystem again and restore the data but of course I would actually need to know what went wrong the first time in order to avoid doing it again. Is there anything you need to know about my system which would be of use? (Controller, Disks, Mainboard etc. ?) The question is, why is this important? The presence of that area won't affect the operation of the FS in the slightest. The FS won't write any data to that area, and it's only 4MiB in size -- completely lost in the noise for a 2.6 TiB filesystem. At worst, it's an extra line of output; slightly messy, but utterly harmless. I think the default kernel for OpenSuSE 13.1 is 3.11, which may be old enough that it doesn't have the patch that allows balancing of chunk 0 (which is probably what's happening here). Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- You are demons, and I am in Hell! Well, technically, it's --- London, but it's an easy mistake to make. signature.asc Description: Digital signature
Re: Confusing output of btrfs fi df
Hi Stefan, On Sat, Apr 26, 2014 at 11:28 PM, Chris Murphy li...@colorremedies.com wrote: They're harmless -- it's a side-effect of the way that mkfs works. They'll go away if you balance them: btrfs balance start -dprofiles=single -mprofiles=single -sprofiles=single /mountpoint btrfs refused this command, I had to pass --force to execute it. It exited with this:Done, had to relocate 2 out of 2710 chunks. After that btrfs fi df shows the following: Data, RAID1: total=2.64TiB, used=2.22TiB System, RAID1: total=8.00MiB, used=380.00KiB System, single: total=4.00MiB, used=0.00 Metadata, RAID1: total=4.00GiB, used=2.94GiB Hmm, seems like a bug. What about See this patch: Btrfs: stop refusing the relocation of chunk 0 I managed to balance away the empty single System chunk only once I was running 3.13 from Ubuntu trusty. http://www.spinics.net/lists/linux-btrfs/msg27119.html https://bugzilla.kernel.org/show_bug.cgi?id=60594 Cheers, Dan -- 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: Which companies are using Btrfs in production?
On Fri, Apr 25, 2014 at 08:20:45AM -0700, Marc MERLIN wrote: There are lots of contributors with the same small amout of patches contributed and are not listed there. This is first time I hear about Netgear being a contributor and it looks strange to see that name among the major contributors. If there's demand to list all the minor contributors, then let's add a separate section, otherwise I'm going to remove the entry. That said, my goal was not to say which company gave the most contributions and try and rank them. Honestly, right now any company that is using btrfs and contributing to it is a great thing in my book. I'm not even a fan of counting number of lines or frequency of patches. How do you compare someone sending easy cleanup patches vs someone who spent a month tracking down a file corruption problem no one could find nor fix, and sends a 3 line patch to fix it in the end? Patch count itself as a metric does not work, I'm roughly calculating amount of work spent on contribution in the area of patches, testing, bugreporting, documentation, community support. For all the companies listed there is a clear record of these activies, that's what they get the credit for. The non-company/community deserve the entry on itself, but I was not discussing community contributions. I really like to see random people sending patches and I try to help them to get patches merged by doing reviews or commenting. How about we leave that decision with Chris Mason? He's been CCed for that purpose and made a statement which I don't have a slightest problem to agree with: I'd be happy to see people add themselves to a we're contributors section if they have been part of progs or kernel releases for a year. Code review, patch submission, and helping users on the list/irc all count. -- 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: Which companies are using Btrfs in production?
On 4/25/14, 10:20 AM, Marc MERLIN wrote: On Fri, Apr 25, 2014 at 04:47:04PM +0200, David Sterba wrote: On Thu, Apr 24, 2014 at 04:14:56PM -0700, Marc MERLIN wrote: Netgear uses BTRFS as the filesystem in their refreshed ReadyNAS line. They apparently use Oracle's linux distro so I assume they're relying on them to do most of the heavy lifting as far as support BTRFS and backporting goes since they're still on 3.0! They also have raid5/6 support so they are probably running BTRFS on top of md. Yes, and any contributions you see coming from me so far, come from NETGEAR. I've been using my gmail account because I can't make our Thanks. https://btrfs.wiki.kernel.org/index.php/Contributors Updated :) There are lots of contributors with the same small amout of patches contributed and are not listed there. This is first time I hear about Netgear being a contributor and it looks strange to see that name among the major contributors. If there's demand to list all the minor contributors, then let's add a separate section, otherwise I'm going to remove the entry. Mmmh. So I'm not Jon Corbet who has all those fancy honed scripts + non trivial time he spends doing this by hand. That said, my goal was not to say which company gave the most contributions and try and rank them. Honestly, right now any company that is using btrfs and contributing to it is a great thing in my book. I'm not even a fan of counting number of lines or frequency of patches. How do you compare someone sending easy cleanup patches vs someone who spent a month tracking down a file corruption problem no one could find nor fix, and sends a 3 line patch to fix it in the end? Just for the record, I certainly didn't mean that my git patch-counting example was the be-all and end-all of contribution accounting - it's just one metric of many; not meant to be inclusive, but might help to avoid missing people or companies who have contributed in this particular way. -Eric -- 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: Which companies contribute to Btrfs?
On Wed, 23 Apr 2014 18:18:34 -0700 Marc MERLIN m...@merlins.org wrote: I writing slides about btrfs for an upcoming talk (at linuxcon) and I was trying to gather a list of companies that contribute code to btrfs. So I just ran into this now. I did a quick gitdm run over the entire btrfs history in the kernel and came up with this: Top changeset contributors by employer Oracle1249 (33.2%) Fujitsu613 (16.3%) Red Hat483 (12.8%) Fusion-IO 296 (7.9%) (None) 288 (7.6%) Novell 203 (5.4%) STRATO AG 152 (4.0%) Couchbase 106 (2.8%) (Consultant)62 (1.6%) (Unknown) 54 (1.4%) Intel 48 (1.3%) New Dream Network 36 (1.0%) Facebook31 (0.8%) IBM 20 (0.5%) FOSS Outreach Program for Women 12 (0.3%) Google 12 (0.3%) (Academia) 11 (0.3%) Parallels 11 (0.3%) HP 10 (0.3%) Datera Inc. 5 (0.1%) I would expect the rankings to change a bit in the near future, if those slackers at Facebook ever get it in gear...:) jon -- 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: kernel BUG at /home/apw/COD/linux/fs/btrfs/extent_io.c:2116! when deleting device or balancing filesystem.
Duncan 1i5t5.duncan at cox.net writes: Jaap Pieroen posted on Sun, 27 Apr 2014 18:30:19 +0200 as excerpted: ... snip Never use btrfsck (or btrfs check) with the --repair option, unless you're about ready to give up on the filesystem and do a mkfs, in which case you aren't risking anything anyway, or unless a dev suggests you run it. The reason being, btrfs check --repair knows how to fix some types of errors, but among the ones it doesn't know how to fix, it can sometimes make the problem worse. At some point it should know most problems and at least not make them worse, but until then, it's not a good risk to take unless you really know what you're doing or it's no risk as the next step is blowing away the filesystem anyway. (btrfs check, without --repair, is fine to run, since it's read-only and thus won't make anything worse. But by the same token, it won't fix anything either, it's simply informational.) I guess I have been lucky. Unfortunately I was locked out of SSH due to unmounting my /home folder, so I didn't copy the error message. But if memory serves me well it only found csum errors which I guess it never corrected. ... You're behind on btrfs-tools. =:^( The latest version is v3.14.1. I guess I like to install my packages via apt :). Since the error was a kernel message I figured it was tool independent. But you are right, I should have tried the latest tools. $ sudo btrfs fi show Label: btrfs_storage uuid: 7ca5f38e-308f-43ab-b3ea-31b3bcd11a0d Total devices 6 FS bytes used 4.57TiB devid1 size 1.82TiB used 1.32TiB path /dev/sde devid2 size 1.82TiB used 1.32TiB path /dev/sdf devid3 size 1.82TiB used 1.32TiB path /dev/sdg devid4 size 931.51GiB used 88.00GiB path /dev/sdb devid6 size 2.73TiB used 947.03GiB path /dev/sdh devid7 size 2.73TiB used 947.03GiB path /dev/sdi Btrfs v3.12 For further reference, whenever you post btrfs fi show, please post btrfs fi df as well, as the two provide complementary information, and the picture without both of them is incomplete. If you'd supplied the btrfs fi df output, we could see what raid level you're running for data/metadata/system, as well as which type of chunks were still left on /dev/sdb. Yep, I dropped the ball here. I did look in the wiki for a list of output required when asking for support, but I couldn't find any. I'll make sure I add it to the wiki for the next person. Here is the output: # btrfs fi df /home/ Data, RAID5: total=4.57TiB, used=4.57TiB System, RAID1: total=32.00MiB, used=352.00KiB Metadata, RAID1: total=7.00GiB, used=5.58GiB Which will tell you I've been adventurous and went for raid5. :) ... You mentioned that you did try scrub and that it fixed some errors, which would be csum errors. But did it leave any unfixed because there wasn't a second, valid copy of the invalid data with which to rewrite it? If it found and fixed all the errors, then you shouldn't be seeing further csum errors like those in the log file, unless more are being created, which would indicate an ongoing problem (perhaps a device going bad). Well, in hindsight I realize the scrub actually did not fix any errors. It reported 6 csums errors, and none of those could be fixed. Which shouldn't be a suprise since currently scrub doesn't fix raid5 errors. My mistake was that I thought these crc errors should be fixed by a balance ( https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg30714.html), but I guess that only applies when you are balancing over an missing drive? I was also under the assumption that a csum error shouldn't prevent relocation of block groups. Of course the kernel bug is presumably locking up your system, not allowing a clean shutdown, in which case you may well have more csum errors due to that. So after rebooting, be sure to run a scrub before you try to balance or device delete, and hopefully eliminate the problem. Even when I do a 'proper' REISUB reboot? But... since you didn't post the df output, we don't know what the remaining content on the device is, data/metadata/system, nor do we know what mode it is, and it could well be that scrub can't remove it due to invalid csums if there's no second, valid copy, as will definitely be the case if it's single or raid0 mode (with data chunks being single by default, tho metadata and system chunks default to raid1 on a multi- device filesystem and dup on a single-device filesystem). If there's no valid second copy to rewrite the bad one with, you may simply have to figure out what file and/or snapshot(s) it belongs to and delete them, fixing the bad csums that way. This is what I'll do as a workaround. It's unfortunate that a balance didn't seem to take care of these checksum errors. Of course that's assuming it's the bad csums causing the problem, not something else. I
Re: Which companies contribute to Btrfs?
On 04/28/2014 03:00 PM, Jonathan Corbet wrote: On Wed, 23 Apr 2014 18:18:34 -0700 Marc MERLIN m...@merlins.org wrote: I writing slides about btrfs for an upcoming talk (at linuxcon) and I was trying to gather a list of companies that contribute code to btrfs. So I just ran into this now. I did a quick gitdm run over the entire btrfs history in the kernel and came up with this: Top changeset contributors by employer Oracle1249 (33.2%) Fujitsu613 (16.3%) Red Hat483 (12.8%) Fusion-IO 296 (7.9%) (None) 288 (7.6%) Novell 203 (5.4%) STRATO AG 152 (4.0%) Couchbase 106 (2.8%) (Consultant)62 (1.6%) (Unknown) 54 (1.4%) Intel 48 (1.3%) New Dream Network 36 (1.0%) Facebook31 (0.8%) IBM 20 (0.5%) FOSS Outreach Program for Women 12 (0.3%) Google 12 (0.3%) (Academia) 11 (0.3%) Parallels 11 (0.3%) HP 10 (0.3%) Datera Inc. 5 (0.1%) I would expect the rankings to change a bit in the near future, if those slackers at Facebook ever get it in gear...:) Grin, Josef has taken a few weeks off to look after the newly released Josefv3. We've got the pool of web servers on btrfs at 800 now, and soon I'm sure it'll start kicking out some fun bugs. Once we get the btrfs tier up to 1000, I'll have a second slice of 1000 machines running 3.14 as well (or whatever the current linus rev is). Those will be btrfs too, I expect the crash recovery code will get quite a bit of testing. -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
partially truncated file after snap rollback, btrfs
Hi, I ran into an odd situation where after a snap rollback, a file appears to be incorrectly truncated. The file in question is part of a ceph-osd backing store. I've attached a grepped and annotated excerpt from the osd log detailing the operations on this file since creation. Ceph sha1: 8603cce1efbdbba9a3054d938394d673b59fd4d1 (wip-sam-btrfs in ceph git) Kernel sha1: f74d66a3ec1b62a663451083091ccb8341d721ec (ceph kernel git, testing branch, based on 3.14) I've got a bunch of additional logging, let me know if there is anything else I can grab. Also, let me know if there is additional information which would be good to have if it recurs. Thanks! -Sam 2014-04-28 05:29:29.756213 7f7fb0de0700 15 filestore(/var/lib/ceph/osd/ceph-1) remove 3.c_head/a5cd460c/plana6123747-15/11e//3 2014-04-28 05:29:29.756245 7f7fb0de0700 10 filestore(/var/lib/ceph/osd/ceph-1) remove 3.c_head/a5cd460c/plana6123747-15/11e//3 = -2 2014-04-28 05:29:29.756253 7f7fb0de0700 15 filestore(/var/lib/ceph/osd/ceph-1) remove 3.c_TEMP/a5cd460c/plana6123747-15/11e//3 2014-04-28 05:29:29.756274 7f7fb0de0700 10 filestore(/var/lib/ceph/osd/ceph-1) remove 3.c_TEMP/a5cd460c/plana6123747-15/11e//3 = -2 2014-04-28 05:29:29.756278 7f7fb0de0700 15 filestore(/var/lib/ceph/osd/ceph-1) touch 3.c_head/a5cd460c/plana6123747-15/11e//3 2014-04-28 05:29:29.756358 7f7fb0de0700 10 filestore(/var/lib/ceph/osd/ceph-1) touch 3.c_head/a5cd460c/plana6123747-15/11e//3 = 0 2014-04-28 05:29:29.756368 7f7fb0de0700 15 filestore(/var/lib/ceph/osd/ceph-1) _omap_setheader 3.c_head/a5cd460c/plana6123747-15/11e//3 2014-04-28 05:29:29.756416 7f7fb0de0700 20 filestore set_map_header: setting 1128 oid a5cd460c/plana6123747-15/11e//3 parent seq 0 2014-04-28 05:29:29.756426 7f7fb0de0700 10 filestore oid: a5cd460c/plana6123747-15/11e//3 not skipping op, *spos 9073.0.3 2014-04-28 05:29:29.756442 7f7fb0de0700 15 filestore(/var/lib/ceph/osd/ceph-1) _omap_setkeys 3.c_head/a5cd460c/plana6123747-15/11e//3 2014-04-28 05:29:29.756489 7f7fb0de0700 10 filestore oid: a5cd460c/plana6123747-15/11e//3 not skipping op, *spos 9073.0.4 2014-04-28 05:29:29.756523 7f7fb0de0700 15 filestore(/var/lib/ceph/osd/ceph-1) setattrs 3.c_head/a5cd460c/plana6123747-15/11e//3 2014-04-28 05:29:29.756565 7f7fb0de0700 10 filestore oid: a5cd460c/plana6123747-15/11e//3 not skipping op, *spos 9073.0.5 2014-04-28 05:29:29.756576 7f7fb0de0700 10 filestore(/var/lib/ceph/osd/ceph-1) setattrs 3.c_head/a5cd460c/plana6123747-15/11e//3 = 0 [The contents of the file are filled in here (twice, apparently) from the adjacent clones. The actual size should be 103955, and the 0~103955 extent happens to be shared with both adjacent clones. It seems to get clone_range'd in from both clones due to a bug in the OSD recovery logic, but that should be unrelated. The logic for the following use of BTRFS_IOC_CLONE_RANGE is in the ceph tree at src/os/BtrfsFileStoreBackend.cc:clone_range https://github.com/ceph/ceph/blob/wip-sam-btrfs/src/os/BtrfsFileStoreBackend.cc] 2014-04-28 05:29:29.756581 7f7fb0de0700 15 filestore(/var/lib/ceph/osd/ceph-1) clone_range 3.c_head/a5cd460c/plana6123747-15/b9//3 - 3.c_head/a5cd460c/plana6123747-15/11e//3 0~103955 to 0 2014-04-28 05:29:29.756593 7f7fb0de0700 20 filestore(/var/lib/ceph/osd/ceph-1) _do_clone_range copy 0~103955 to 0 [The clone range from the first clone, b9, seems to successfully clone 102400 bytes (rounded since the file size is not the same as the clone_range length), and the remaining 1555 is written in] 2014-04-28 05:29:29.756595 7f7fb0de0700 20 btrfsfilestorebackend(/var/lib/ceph/osd/ceph-1) clone_range: 0~103955 to 0 2014-04-28 05:29:29.756597 7f7fb0de0700 20 btrfsfilestorebackend(/var/lib/ceph/osd/ceph-1) clone_range: cloning 0~102400 to 0 = 0 2014-04-28 05:29:29.756620 7f7fb0de0700 20 filestore(/var/lib/ceph/osd/ceph-1) _do_copy_range 102400~1555 to 102400 2014-04-28 05:29:29.756635 7f7fb0de0700 20 filestore(/var/lib/ceph/osd/ceph-1) _do_copy_range 102400~1555 to 102400 = 1555 2014-04-28 05:29:29.756638 7f7fb0de0700 20 btrfsfilestorebackend(/var/lib/ceph/osd/ceph-1) clone_range: finished 0~103955 to 0 = 1555 2014-04-28 05:29:29.756640 7f7fb0de0700 10 filestore(/var/lib/ceph/osd/ceph-1) clone_range 3.c_head/a5cd460c/plana6123747-15/b9//3 - 3.c_head/a5cd460c/plana6123747-15/11e//3 0~103955 to 0 = 1555 2014-04-28 05:29:29.756645 7f7fb0de0700 15 filestore(/var/lib/ceph/osd/ceph-1) clone_range 3.c_head/a5cd460c/plana6123747-15/126//3 - 3.c_head/a5cd460c/plana6123747-15/11e//3 0~103955 to 0 2014-04-28 05:29:29.756658 7f7fb0de0700 20 filestore(/var/lib/ceph/osd/ceph-1) _do_clone_range copy 0~103955 to 0 2014-04-28 05:29:29.756659 7f7fb0de0700 20 btrfsfilestorebackend(/var/lib/ceph/osd/ceph-1) clone_range: 0~103955 to 0 [The second clone range from the second clone, 126, appears to successfully clone the full 103955 (not rounded since it matches the file size) bytes over the same extent as before] 2014-04-28 05:29:29.756662 7f7fb0de0700 20
Re: Which companies contribute to Btrfs?
On Mon, Apr 28, 2014 at 2:00 PM, Jonathan Corbet cor...@lwn.net wrote: On Wed, 23 Apr 2014 18:18:34 -0700 Marc MERLIN m...@merlins.org wrote: I writing slides about btrfs for an upcoming talk (at linuxcon) and I was trying to gather a list of companies that contribute code to btrfs. So I just ran into this now. I did a quick gitdm run over the entire btrfs history in the kernel and came up with this: Top changeset contributors by employer Oracle1249 (33.2%) ... Fusion-IO 296 (7.9%) ... Facebook31 (0.8%) I wonder how much of this is actually due to Chris Mason changing his email address. -- 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: Which companies contribute to Btrfs?
On 04/28/2014 08:06 PM, Chester wrote: On Mon, Apr 28, 2014 at 2:00 PM, Jonathan Corbet cor...@lwn.net wrote: On Wed, 23 Apr 2014 18:18:34 -0700 Marc MERLIN m...@merlins.org wrote: I writing slides about btrfs for an upcoming talk (at linuxcon) and I was trying to gather a list of companies that contribute code to btrfs. So I just ran into this now. I did a quick gitdm run over the entire btrfs history in the kernel and came up with this: Top changeset contributors by employer Oracle1249 (33.2%) ... Fusion-IO 296 (7.9%) ... Facebook31 (0.8%) I wonder how much of this is actually due to Chris Mason changing his email address. Most of those are really Josef, but it's the right idea. -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: do not increment on bio_index one by one
'bio_index' is just a index, it's really not necessary to do increment
one by one.
Signed-off-by: Liu Bo bo.li@oracle.com
---
fs/btrfs/file-item.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/file-item.c b/fs/btrfs/file-item.c
index 9d84658..344b89c 100644
--- a/fs/btrfs/file-item.c
+++ b/fs/btrfs/file-item.c
@@ -281,10 +281,10 @@ static int __btrfs_lookup_bio_sums(struct btrfs_root
*root,
found:
csum += count * csum_size;
nblocks -= count;
+ bio_index += count;
while (count--) {
disk_bytenr += bvec-bv_len;
offset += bvec-bv_len;
- bio_index++;
bvec++;
}
}
--
1.8.1.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
[PATCH] Btrfs: make log message easier to grep for
While greping for you don't have the default diritem, this isn't going to
work,
I found it's just hard since we use
printk(...default dir
item ...);
To make developer's life easier, I checked all the similar code and made it
easier to grep for.
Signed-off-by: Liu Bo bo.li@oracle.com
---
fs/btrfs/delayed-inode.c| 8 ++--
fs/btrfs/extent-tree.c | 4 ++--
fs/btrfs/extent_io.c| 6 ++
fs/btrfs/free-space-cache.c | 3 +--
fs/btrfs/ioctl.c| 7 +++
fs/btrfs/qgroup.c | 6 ++
fs/btrfs/scrub.c| 9 +++--
fs/btrfs/send.c | 4 +---
fs/btrfs/volumes.c | 9 +++--
9 files changed, 19 insertions(+), 37 deletions(-)
diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c
index 33e561a..4160778 100644
--- a/fs/btrfs/delayed-inode.c
+++ b/fs/btrfs/delayed-inode.c
@@ -1492,9 +1492,7 @@ int btrfs_insert_delayed_dir_index(struct
btrfs_trans_handle *trans,
mutex_lock(delayed_node-mutex);
ret = __btrfs_add_delayed_insertion_item(delayed_node, delayed_item);
if (unlikely(ret)) {
- btrfs_err(root-fs_info, err add delayed dir index item(name:
%.*s)
- into the insertion tree of the delayed node
- (root id: %llu, inode id: %llu, errno: %d),
+ btrfs_err(root-fs_info, err add delayed dir index item(name:
%.*s) into the insertion tree of the delayed node (root id: %llu, inode id:
%llu, errno: %d),
name_len, name, delayed_node-root-objectid,
delayed_node-inode_id, ret);
BUG();
@@ -1564,9 +1562,7 @@ int btrfs_delete_delayed_dir_index(struct
btrfs_trans_handle *trans,
mutex_lock(node-mutex);
ret = __btrfs_add_delayed_deletion_item(node, item);
if (unlikely(ret)) {
- btrfs_err(root-fs_info, err add delayed dir index item(index:
%llu)
- into the deletion tree of the delayed node
- (root id: %llu, inode id: %llu, errno: %d),
+ btrfs_err(root-fs_info, err add delayed dir index item(index:
%llu) into the deletion tree of the delayed node (root id: %llu, inode id:
%llu, errno: %d),
index, node-root-objectid, node-inode_id,
ret);
BUG();
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 5590af9..911abf4 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -5805,8 +5805,8 @@ static int __btrfs_free_extent(struct btrfs_trans_handle
*trans,
refs = btrfs_extent_refs(leaf, ei);
if (refs refs_to_drop) {
- btrfs_err(info, trying to drop %d refs but we only have %Lu
- for bytenr %Lu\n, refs_to_drop, refs, bytenr);
+ btrfs_err(info, trying to drop %d refs but we only have %llu
for bytenr %llu\n,
+ refs_to_drop, refs, bytenr);
ret = -EINVAL;
btrfs_abort_transaction(trans, extent_root, ret);
goto out;
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 0c43896..80be17c 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -2401,8 +2401,7 @@ static void end_bio_extent_writepage(struct bio *bio, int
err)
bvec-bv_offset, bvec-bv_len);
else
btrfs_info(BTRFS_I(page-mapping-host)-root-fs_info,
- incomplete page write in btrfs with offset
%u and
- length %u,
+ incomplete page write in btrfs with offset
%u and length %u,
bvec-bv_offset, bvec-bv_len);
}
@@ -2484,8 +2483,7 @@ static void end_bio_extent_readpage(struct bio *bio, int
err)
bvec-bv_offset, bvec-bv_len);
else
btrfs_info(BTRFS_I(page-mapping-host)-root-fs_info,
- incomplete page read in btrfs with offset
%u and
- length %u,
+ incomplete page read in btrfs with offset
%u and length %u,
bvec-bv_offset, bvec-bv_len);
}
diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
index 73f3de7..904959e 100644
--- a/fs/btrfs/free-space-cache.c
+++ b/fs/btrfs/free-space-cache.c
@@ -668,8 +668,7 @@ static int __load_free_space_cache(struct btrfs_root *root,
struct inode *inode,
if (BTRFS_I(inode)-generation != generation) {
btrfs_err(root-fs_info,
- free space inode generation (%llu)
- did not match free space cache generation
color box, display box, corrugated box, color card, blister card, color sleeve, hang tag, label
Hi, this is David Wu from Shanghai, China. We are a printing company, we can print color box, corrugated box, label, hang tag etc. Please let me know if you need these. I will send you the website then. Best regards, David Wu -- 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
