Re: *** GMX Spamverdacht *** Re: btrfs GPF in read_extent_buffer() while scrubbing with kernel 3.4.2
On 07.07.2012 01:44, Sami Liedes wrote: [Retry: I think this mail didn't make it to the list, probably because of the 73 kilobyte attached log. Here's a URL to the file:] http://www.niksula.hut.fi/~sliedes/btrfs-scrub-debug.log.gz Sami On Fri, Jul 06, 2012 at 05:09:00PM +0200, Jan Schmidt wrote: Oh I see. root-node can be NULL during mount. Please add this on top: Ok. So, ran it with DEBUG_PAGEALLOC and slub debugging on. This time it took half an hour to crash, and there's _lots_ of checksum mismatch [234] messages even before the crash. gzipped dmesg attached. At 781 seconds there's an irq 17: nobody cared. That's a known bug with this (and other Asus) motherboards and happens every now and then. I doubt it has anything to do with this. I think I might try running it overnight with KMEMCHECK to see if it reports something. But for now, what there's in the log: * lots of checksum mismatch [234], no 1s * a fair number of csum_tree_block: [0-9]+ callbacks suppressed lines * two btrfs: node seems invalid now. checksum ok = 1 messages, one at 1499 seconds and another just before the crash at 1973 * Just before the crash: btrfs: invalid parameters for read_extent_buffer: start (32771) eb-len (32768). eb start is 2261163409408, level 100, generation 4412718571037421157, nritems 538968254. len param 17. debug 2/989/538968254/4412718571037421157/0x0/0/0x0/0x0 At a first glance: the generation converted to ascii is: ent() ==, so someone is patching the memory with ascii text, possibly C source. It might be interesting to dump the full contents of the eb, to get a clue on the source of the data. * the oopses By the way, something seems to be untabifying your patches. I don't know if it's on my side or yours, but at least some other patches I receive via linux-btrfs contain tabs. Doing a M-x tabify in emacs mostly makes them apply cleanly for me. Oh, I'm sorry. Should have been on my side. I hope it's better with the current diff? Yes. No problem :) [See attachment for dmesg log.] Sami -- 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
Re: [RFC] Btrfs sendshots and hidden snapshots
On 07/06/2012 02:45 PM, Alexander Block wrote: On Fri, Jul 6, 2012 at 2:03 PM, Goffredo Baroncelli kreij...@libero.it wrote: On 07/06/2012 01:55 PM, Chris Mason wrote: On Fri, Jul 06, 2012 at 02:51:43AM -0600, Alexander Block wrote: On Fri, Jul 6, 2012 at 12:34 AM, Goffredo Baroncelli kreij...@libero.it wrote: On 07/05/2012 06:51 PM, Alexander Block wrote: Hello all, in IRC we had a discussion on how we could solve sending live subvolumes and how to send subvolumes without the need to administrate/keep old snapshots for incremental sends. One of the ideas was to introduce sendshots, which are basically snapshots where no refs are counted for file data. This means, that when file data is changed in the sendshot origin, we do not consume extra space for two copies of the data. We would only have the metadata duplicated. For the initial btrfs send we could do this: 1. Create a hidden read-only snapshot of the subvolume to send. Hidden means that it's not referenced by any subvolume. It is however still a normal snapshot (not a sendshot!). Hidden snapshots are not possible atm so we would have to implement that. This step allows us to send read-write subvolumes, because we have a freezed version of it. Why we should want/need an hidden snapshot ? We could put this kind of hidden snapshot under a directory dot-prefixed (like /.hidden-subvolumes) That would have the problem that the user may modify the subvolume in-between (by removing the ro flag). Or he could simple cd into it and we would later fail to delete it. I prefer to make this more explicit. We could add a hard-readonly flag that cannot be cleared. Having the snapshot show in the FS lets the admin know what things are really using space. Yepp sounds like a better solution then hidden snapshots. Or, we could protect against RO flag changes while performing the send. Me too, but I am guessing what should happens when the users try to read an old data ? (I am talking about sendshot ). If I understood correctly the old data isn't tracked by the sendshot. Two possible solutions that I see: 1. Hidden sendshots :P 2. Reading files from a sendshot will always give dummy data (e.g. all zero). But I really can't estimate how hard this is to implement. From an user point of view, this would be a nightmare. Two similar filesystem with no obvious differences I suggest that the sendshot appears as empty read only subvolume. So all the btrfs subvolumes semantic could be applied (btrfs subvolume delete, btrfs sublume list, btrfs send, btrfs receive ) and the user cannot read false data. We could mark this with a specific inode number:currently all subvolume have inode number=256, we could use 255 or similar (I don't know if this could raise some problem however ). Otherwise we need to create a separate namespace for this kind of subvolume (which could be a solution for other kinds of problems), for example under /sys. GB GB . -- 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 0/2] Support for small units in display
Allow better inspection of sizes using an environment variable. Not pretty, but convenient to determine the exact size of a filesystem, eg when resizing an underlying partition or LUN. Pierre Carrier (2): utils.c: fix sizes in B malloc in pretty_sizes utils.c: offer to limit divisions in pretty_sizes utils.c | 18 +++--- 1 file changed, 15 insertions(+), 3 deletions(-) -- 1.7.11.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 1/2] utils.c: fix sizes in B malloc in pretty_sizes
Before, sizes below 1KB where displayed in KB,
but without a unit.
Signed-off-by: Pierre Carrier pie...@spotify.com
diff --git a/utils.c b/utils.c
index aade9e2..dde0513 100644
--- a/utils.c
+++ b/utils.c
@@ -1108,13 +1108,20 @@ char *pretty_sizes(u64 size)
size /= 1024;
num_divs++;
}
- if (num_divs == 0)
+ if (num_divs == 0) {
num_divs = 1;
+ fraction = (float)fract_size;
+ } else
+ fraction = (float)fract_size / 1024;
+
if (num_divs ARRAY_SIZE(size_strs))
return NULL;
- fraction = (float)fract_size / 1024;
+
pretty = malloc(pretty_len);
+ if (!pretty)
+ return NULL;
+
snprintf(pretty, pretty_len, %.2f%s, fraction, size_strs[num_divs-1]);
return pretty;
}
--
1.7.11.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 0/2] Support for small units in display
I didn't test the initial patches enough. A second round is coming. This time it works fine: devid1 size 66746609664.00 used 66746580992.00 path /dev/sda5 devid1 size 65182236.00KB used 65182208.00KB path /dev/sda5 devid1 size 63654.53MB used 63654.50MB path /dev/sda5 devid1 size 62.16GB used 62.16GB path /dev/sda5 devid1 size 62.16GB used 62.16GB path /dev/sda5 Pierre Carrier (2): utils.c: fix sizes in B malloc in pretty_sizes utils.c: offer to limit divisions in pretty_sizes utils.c | 17 ++--- 1 file changed, 14 insertions(+), 3 deletions(-) -- 1.7.11.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 1/2] utils.c: fix sizes in B malloc in pretty_sizes
Before, sizes below 1KB are still displayed in KB,
but without a unit.
Signed-off-by: Pierre Carrier pie...@spotify.com
diff --git a/utils.c b/utils.c
index aade9e2..937e763 100644
--- a/utils.c
+++ b/utils.c
@@ -1108,13 +1108,20 @@ char *pretty_sizes(u64 size)
size /= 1024;
num_divs++;
}
- if (num_divs == 0)
+ if (num_divs = 1) {
num_divs = 1;
+ fraction = (float)fract_size;
+ } else
+ fraction = (float)fract_size / 1024;
+
if (num_divs ARRAY_SIZE(size_strs))
return NULL;
- fraction = (float)fract_size / 1024;
+
pretty = malloc(pretty_len);
+ if (!pretty)
+ return NULL;
+
snprintf(pretty, pretty_len, %.2f%s, fraction, size_strs[num_divs-1]);
return pretty;
}
--
1.7.11.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 2/2] utils.c: offer to limit divisions in pretty_sizes
Dirty hack to allow inspection of sizes in lower units.
Useful to know the minimum size a partition shoud be resized to
after a 'btrfs filesystem resize'.
Label: 'home' uuid: 10453c4c-1c5b-4df5-b4a5-43a7f377430a
Total devices 1 FS bytes used 42.80GB
devid1 size 62.16GB used 62.16GB path /dev/sda5
Label: 'home' uuid: 10453c4c-1c5b-4df5-b4a5-43a7f377430a
Total devices 1 FS bytes used 44884524.00KB
devid1 size 65182236.00KB used 65182208.00KB path /dev/sda5
Signed-off-by: Pierre Carrier pie...@spotify.com
diff --git a/utils.c b/utils.c
index 937e763..3f0b7e7 100644
--- a/utils.c
+++ b/utils.c
@@ -1096,13 +1096,18 @@ static char *size_strs[] = { , KB, MB, GB, TB,
char *pretty_sizes(u64 size)
{
int num_divs = 0;
+ int max_divs = INT_MAX;
int pretty_len = 16;
u64 last_size = size;
u64 fract_size = size;
float fraction;
char *pretty;
+ char *max_divs_s;
- while(size 0) {
+ if (max_divs_s = getenv(MAX_DIVS))
+ max_divs = atoi(max_divs_s);
+
+ while(size 0 num_divs = max_divs) {
fract_size = last_size;
last_size = size;
size /= 1024;
@@ -1117,7 +1122,6 @@ char *pretty_sizes(u64 size)
if (num_divs ARRAY_SIZE(size_strs))
return NULL;
-
pretty = malloc(pretty_len);
if (!pretty)
return NULL;
--
1.7.11.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
Re: [PATCH] fix unaligned memory accesses (Closes: #656955)
On Fri, Jul 06, 2012 at 07:37:42PM -0600, Shawn Landden wrote: From: Shawn Landen shawnland...@gmail.com Fix creation of volumes using mkfs.btrfs on armv5. [ use memcpy instead of direct structure accesses ] Thanks for the patch. This should be a problem in the way gcc is run. The kernel uses the same functions without memcpy, so there must be a way to get gcc to turn the unaligned access into something arch safe. -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: [RFC PATCH 6/6] Btrfs-progs: add btrfs send/receive commands
Hi Alexander, I studied all the kernel + user code, and I have a long list of questions. Meanwhile, I want to report two small bugs: # BTRFS_SEND_C_MKNOD command: the receive path expects BTRFS_SEND_A_MODE, but kernel doesn't send it. So currently it errors. It looks like kernel need to send it, otherwise how do we know which kind of mknod to create. # BTRFS_SEND_C_LINK - process_link() ret = link(lnk, full_path); == I think it should be the other way around, the old path comes first and then the new path. Otherwise, it fails. If you prefer, I can send you patches for those. I will keep playing with your code let you know what else I find. Thanks! Alex. -- 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 1/3] btrfs: extended inode refs
On Fri, Jul 06, 2012 at 04:56:40PM +0200, Jan Schmidt wrote:
Hi Mark,
Sorry, I'm a bit late with my feedback.
No problem, thank you for taking the time to read these patches! Reply to
your most substantial comment is below. Everything else you pointed out I'll
have fixed up for an updated patch (don't think I need to reply individually
to those).
On Mon, May 21, 2012 at 23:46 (+0200), Mark Fasheh wrote:
@@ -189,6 +435,19 @@ int btrfs_insert_inode_ref(struct btrfs_trans_handle
*trans,
out:
btrfs_free_path(path);
+
+ if (ret == -EMLINK) {
+ struct btrfs_super_block *disk_super =
root-fs_info-super_copy;
+ /* We ran out of space in the ref array. Need to
+* add an extended ref. */
+ if (btrfs_super_incompat_flags(disk_super)
+BTRFS_FEATURE_INCOMPAT_EXTENDED_IREF)
Uhm. Good place to check here. But please help me to find the place where this
is added to the super block's flags in the first place.
mkfs.btrfs :)
The kernel should never be adding the flag as things are currently designed.
Thanks again!
--Mark
--
Mark Fasheh
--
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 fi df won't show total=
On openSUSE_12.1 with Btrfs v0.19+20120406, the following can be observed: after a change of the profiles, total=,used= is no longer shown: 20:49 mmsrv1:~ # btrfs fi df /top.srv/ Data, RAID10: total=152.00GiB, used=121.07GiB System, RAID1: total=40.00MiB, used=44.00KiB System: total=4.00MiB, used=0.00 Metadata, RAID1: total=112.00GiB, used=1.30GiB Metadata: total=8.00MiB, used=0.00 20:50 mmsrv1:~ # btrfs fi bal start -mconvert=raid10 -sconvert=raid10 /top.srv/ Refusing to explicitly operate on system chunks. Pass --force if you really want to do that. 20:52 mmsrv1:~ # btrfs fi bal start -mconvert=raid10 -sconvert=raid10 --force /top.srv/ ... 21:10 mmsrv1:~ # btrfs fi df /top.srv/ Data, RAID10: total=156.00GiB, used=124.35GiB System, RAID10: total=128.00MiB, used=48.00KiB System: total=4.00MiB, used=0.00 Metadata, RAID10: total=112.00GiB, used=1.38GiB -- 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 df won't show total=
On Mon, Jul 09, 2012 at 09:14:03PM +0200, Jan Engelhardt wrote: On openSUSE_12.1 with Btrfs v0.19+20120406, the following can be observed: after a change of the profiles, total=,used= is no longer shown: 20:49 mmsrv1:~ # btrfs fi df /top.srv/ Data, RAID10: total=152.00GiB, used=121.07GiB System, RAID1: total=40.00MiB, used=44.00KiB System: total=4.00MiB, used=0.00 Metadata, RAID1: total=112.00GiB, used=1.30GiB Metadata: total=8.00MiB, used=0.00 20:50 mmsrv1:~ # btrfs fi bal start -mconvert=raid10 -sconvert=raid10 /top.srv/ Refusing to explicitly operate on system chunks. Pass --force if you really want to do that. 20:52 mmsrv1:~ # btrfs fi bal start -mconvert=raid10 -sconvert=raid10 --force /top.srv/ ... 21:10 mmsrv1:~ # btrfs fi df /top.srv/ Data, RAID10: total=156.00GiB, used=124.35GiB System, RAID10: total=128.00MiB, used=48.00KiB System: total=4.00MiB, used=0.00 Metadata, RAID10: total=112.00GiB, used=1.38GiB What's the problem here? You no longer have any RAID1 chunks, so it's not showing them. 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 --- IMPROVE YOUR ORGANISMS!! -- Subject line of spam email --- signature.asc Description: Digital signature
Re: btrfs fi df won't show total=
On Monday 2012-07-09 21:25, Hugo Mills wrote: On Mon, Jul 09, 2012 at 09:14:03PM +0200, Jan Engelhardt wrote: On openSUSE_12.1 with Btrfs v0.19+20120406, the following can be observed: after a change of the profiles, total=,used= is no longer shown: 20:49 mmsrv1:~ # btrfs fi df /top.srv/ Data, RAID10: total=152.00GiB, used=121.07GiB System, RAID1: total=40.00MiB, used=44.00KiB System: total=4.00MiB, used=0.00 Metadata, RAID1: total=112.00GiB, used=1.30GiB Metadata: total=8.00MiB, used=0.00 [...] 21:10 mmsrv1:~ # btrfs fi df /top.srv/ Data, RAID10: total=156.00GiB, used=124.35GiB System, RAID10: total=128.00MiB, used=48.00KiB System: total=4.00MiB, used=0.00 Metadata, RAID10: total=112.00GiB, used=1.38GiB What's the problem here? You no longer have any RAID1 chunks, so it's not showing them. Rather tha a 4-line output, I would have expected this 6-line output that I would also get when mkfs'ing a new fresh btrfs volume with raid10 from the start: Data, RAID10: total=156.00GiB, used=124.35GiB Data: total=foo, used=bar System, RAID10: total=128.00MiB, used=48.00KiB System: total=4.00MiB, used=0.00 Metadata, RAID10: total=112.00GiB, used=1.38GiB Metadata: total=foo, used=bar -- 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 df won't show total=
On Mon, Jul 09, 2012 at 10:06:24PM +0200, Jan Engelhardt wrote: On Monday 2012-07-09 21:25, Hugo Mills wrote: On Mon, Jul 09, 2012 at 09:14:03PM +0200, Jan Engelhardt wrote: On openSUSE_12.1 with Btrfs v0.19+20120406, the following can be observed: after a change of the profiles, total=,used= is no longer shown: 20:49 mmsrv1:~ # btrfs fi df /top.srv/ Data, RAID10: total=152.00GiB, used=121.07GiB System, RAID1: total=40.00MiB, used=44.00KiB System: total=4.00MiB, used=0.00 Metadata, RAID1: total=112.00GiB, used=1.30GiB Metadata: total=8.00MiB, used=0.00 [...] 21:10 mmsrv1:~ # btrfs fi df /top.srv/ Data, RAID10: total=156.00GiB, used=124.35GiB System, RAID10: total=128.00MiB, used=48.00KiB System: total=4.00MiB, used=0.00 Metadata, RAID10: total=112.00GiB, used=1.38GiB What's the problem here? You no longer have any RAID1 chunks, so it's not showing them. Rather tha a 4-line output, I would have expected this 6-line output that I would also get when mkfs'ing a new fresh btrfs volume with raid10 from the start: Data, RAID10: total=156.00GiB, used=124.35GiB Data: total=foo, used=bar System, RAID10: total=128.00MiB, used=48.00KiB System: total=4.00MiB, used=0.00 Metadata, RAID10: total=112.00GiB, used=1.38GiB Metadata: total=foo, used=bar The lines without the RAID marker are there as a result of the way that mkfs works -- it creates stub chunks which are never used, and then upgrades to the required RAID level immediately afterwards. The balance (any balance, not just a conversion) processes these chunks as well as all the other chunks in the FS, and rewrites all of the data in them (all 0 bytes of it) somewhere else, removing the originals. 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 --- Well, you don't get to be a kernel hacker simply by looking --- good in Speedos. -- Rusty Russell signature.asc Description: Digital signature
Re: [PATCH 1/3] btrfs: extended inode refs
diff --git a/fs/btrfs/inode-item.c b/fs/btrfs/inode-item.c
index baa74f3..496fb1c 100644
--- a/fs/btrfs/inode-item.c
+++ b/fs/btrfs/inode-item.c
@@ -18,6 +18,7 @@
#include ctree.h
#include disk-io.h
+#include hash.h
#include transaction.h
static int find_name_in_backref(struct btrfs_path *path, const char *name,
@@ -49,18 +50,56 @@ static int find_name_in_backref(struct btrfs_path
*path, const char *name,
return 0;
}
-struct btrfs_inode_ref *
+int find_name_in_ext_backref(struct btrfs_path *path, const char *name,
+int name_len,
+struct btrfs_inode_extref **extref_ret)
Exported functions should be prefixed btrfs_. What about
btrfs_find_extref_name?
+{
+ struct extent_buffer *leaf;
+ struct btrfs_inode_extref *extref;
+ unsigned long ptr;
+ unsigned long name_ptr;
+ u32 item_size;
+ u32 cur_offset = 0;
+ int ref_name_len;
+
+ leaf = path-nodes[0];
+ item_size = btrfs_item_size_nr(leaf, path-slots[0]);
+ ptr = btrfs_item_ptr_offset(leaf, path-slots[0]);
+
+ /*
+* Search all extended backrefs in this item. We're only
+* looking through any collisions so most of the time this is
+* just going to compare against one buffer. If all is well,
+* we'll return success and the inode ref object.
+*/
+ while (cur_offset item_size) {
+ extref = (struct btrfs_inode_extref *) (ptr + cur_offset);
+ name_ptr = (unsigned long)(extref-name);
+ ref_name_len = btrfs_inode_extref_name_len(leaf, extref);
+
+ if (ref_name_len == name_len
+(memcmp_extent_buffer(leaf, name, name_ptr, name_len) ==
0)) {
+ if (extref_ret)
+ *extref_ret = extref;
+ return 1;
+ }
+
+ cur_offset += ref_name_len + sizeof(*extref);
+ }
+ return 0;
For consistency, I'd like to switch return 0 and 1.
Ok so btrfs_find_name_in_ext_backref() is designed to mirror
btrfs_find_name_in_backref() for obvious reasons - it does the same thing
except for extended backrefs. So it'd actually be inconsistent if I change
this (unless I change both but I don't think we want to do that).
The name is kept without the btrfs_ prefix for the same reasons, however I
don't think prefixing it is a big deal so I'll go ahead and make _that_
change unless you feel otherwise.
Thanks,
--Mark
--
Mark Fasheh
--
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: btrfs-image: don't segfault if no root is found
Error reporting is already done, so just return if root is NULL, instead of segfaulting: Program received signal SIGSEGV, Segmentation fault. 0x0042cd34 in create_metadump (input=0x7fffe847 /usr/share, out=0x63e010, num_threads=0, compress_level=0) at btrfs-image.c:494 494 BUG_ON(root-nodesize != root-leafsize); at btrfs-image.c:494 Signed-off-by: Arnd Hannemann a...@arndnet.de --- btrfs-image.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/btrfs-image.c b/btrfs-image.c index f2bbcc8..fec51d8 100644 --- a/btrfs-image.c +++ b/btrfs-image.c @@ -491,6 +491,8 @@ static int create_metadump(const char *input, FILE *out, int num_threads, int ret; root = open_ctree(input, 0, 0); + if (!root) + return 1; BUG_ON(root-nodesize != root-leafsize); ret = metadump_init(metadump, root, out, num_threads, -- 1.7.9.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
Re: btrfsck crashes
Anand Jain schrieb: What I have seen: buf is 0, after read_tree_block. Yes since we not checking extent_buffer_uptodate for the csum_root_tree, that will pass the null buf, The following patch will avoid sending null buffer https://patchwork.kernel.org/patch/1148831/ However whether --init-csum-tree will build the good csum I think that will still depends on the corruption IMO. -Anand .) The patch does not help. This is false: !extent_buffer_uptodate(info-csum_root-node) .) Output btrfsck of git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git , patched at line 3552. speedy:/tmp/btrfs/btrfs-progs # gdb ./btrfsck GNU gdb (GDB) SUSE (7.3-41.1.2) Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-suse-linux. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /tmp/btrfs/btrfs-progs/btrfsck...done. (gdb) r /dev/md3 Starting program: /tmp/btrfs/btrfs-progs/btrfsck /dev/md3 Missing separate debuginfo for /lib64/ld-linux-x86-64.so.2 Try: zypper install -C debuginfo(build-id)=f20c99249f5a5776e1377d3bd728502e3f455a3f Missing separate debuginfo for /lib64/libuuid.so.1 Try: zypper install -C debuginfo(build-id)=24ae727f9cd5fb29f81b0f965859d3cf4668bf17 Missing separate debuginfo for /lib64/libc.so.6 Try: zypper install -C debuginfo(build-id)=7b169b1db50384b70e3e4b4884cd56432d5de796 checking extents checksum verify failed on 2327654400 wanted 89AAEA38 found 72 checksum verify failed on 2327654400 wanted 89AAEA38 found 72 checksum verify failed on 2327654400 wanted 73CDE79C found 72 checksum verify failed on 2327654400 wanted 89AAEA38 found 72 Csum didn't match owner ref check failed [2327654400 4096] ref mismatch on [101138354176 98304] extent item 1, found 0 Incorrect local backref count on 101138354176 root 5 owner 1867898 offset 0 found 0 wanted 1 back 0x182ebd20 backpointer mismatch on [101138354176 98304] owner ref check failed [101138354176 98304] ref mismatch on [101138452480 106496] extent item 1, found 0 Incorrect local backref count on 101138452480 root 5 owner 1867899 offset 0 found 0 wanted 1 back 0xefb8d0 backpointer mismatch on [101138452480 106496] owner ref check failed [101138452480 106496] ref mismatch on [101138558976 8192] extent item 1, found 0 Incorrect local backref count on 101138558976 root 5 owner 1867901 offset 0 found 0 wanted 1 back 0x5a22350 backpointer mismatch on [101138558976 8192] owner ref check failed [101138558976 8192] ref mismatch on [101138567168 16384] extent item 1, found 0 Incorrect local backref count on 101138567168 root 5 owner 1867902 offset 0 found 0 wanted 1 back 0x5a22390 backpointer mismatch on [101138567168 16384] owner ref check failed [101138567168 16384] ref mismatch on [101138583552 16384] extent item 1, found 0 Incorrect local backref count on 101138583552 root 5 owner 1867903 offset 0 found 0 wanted 1 back 0x19dfaae0 backpointer mismatch on [101138583552 16384] owner ref check failed [101138583552 16384] Errors found in extent allocation tree checking fs roots checksum verify failed on 2327654400 wanted 89AAEA38 found 72 checksum verify failed on 2327654400 wanted 89AAEA38 found 72 checksum verify failed on 2327654400 wanted 73CDE79C found 72 checksum verify failed on 2327654400 wanted 89AAEA38 found 72 Csum didn't match Program received signal SIGSEGV, Segmentation fault. 0x00402264 in btrfs_header_level (eb=0x0) at ctree.h:1540 1540BTRFS_SETGET_HEADER_FUNCS(header_level, struct btrfs_header, level, 8); (gdb) .) Against which git should I regular patch? This git from the wiki seems to be not up to date: http://git.darksatanic.net/repo/btrfs-progs-unstable.git This repository does not match from the line number: git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git .) Strange for me: Why seems the same number 2327654400 wants to have a different checksum? checksum verify failed on 2327654400 wanted 89AAEA38 found 72 checksum verify failed on 2327654400 wanted 73CDE79C found 72 Thanks regards, Christian On 09/07/12 00:08, Christian Volkmann wrote: Hi there, I have a corrupted filesystem. This filesystem crashes btrfsck. A gdb anaylsis showed me: (gdb) bt #0 0x00402379 in btrfs_header_nritems (eb=0x0) at ctree.h:1426 #1 0x00408c14 in run_next_block (root=0x73fb40, bits=0x740d50, bits_nr=1024, last=0x7fffd948, pending=0x7fffda40, seen=0x7fffda50, reada=0x7fffda30, nodes=0x7fffda20, extent_cache=0x7fffda60) at btrfsck.c:2512 #2 0x004099e2 in check_extents (root=0x73fb40) at btrfsck.c:2792 #3 0x00409bec in main (ac=1, av=0x7fffdbe8) at btrfsck.c:2853 What I have seen: buf is 0,
Re: btrfs fi df won't show total=
On Mon, Jul 09, 2012 at 10:06:24PM +0200, Jan Engelhardt wrote: On Monday 2012-07-09 21:25, Hugo Mills wrote: On Mon, Jul 09, 2012 at 09:14:03PM +0200, Jan Engelhardt wrote: On openSUSE_12.1 with Btrfs v0.19+20120406, the following can be observed: after a change of the profiles, total=,used= is no longer shown: 20:49 mmsrv1:~ # btrfs fi df /top.srv/ Data, RAID10: total=152.00GiB, used=121.07GiB System, RAID1: total=40.00MiB, used=44.00KiB System: total=4.00MiB, used=0.00 Metadata, RAID1: total=112.00GiB, used=1.30GiB Metadata: total=8.00MiB, used=0.00 [...] 21:10 mmsrv1:~ # btrfs fi df /top.srv/ Data, RAID10: total=156.00GiB, used=124.35GiB System, RAID10: total=128.00MiB, used=48.00KiB System: total=4.00MiB, used=0.00 Metadata, RAID10: total=112.00GiB, used=1.38GiB What's the problem here? You no longer have any RAID1 chunks, so it's not showing them. Rather tha a 4-line output, I would have expected this 6-line output that I would also get when mkfs'ing a new fresh btrfs volume with raid10 from the start: Data, RAID10: total=156.00GiB, used=124.35GiB Data: total=foo, used=bar System, RAID10: total=128.00MiB, used=48.00KiB System: total=4.00MiB, used=0.00 Metadata, RAID10: total=112.00GiB, used=1.38GiB Metadata: total=foo, used=bar mkfs creates those non-raid chunks for a pretty stupid reason, they really shouldn't be there if you create a raid10 fs. Balance does the right thing and removes them. Fixing this along with another mkfs annoyance related to this one is on my TODO list. Thanks, Ilya -- 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
3.5.0-rc6: btrfs and LVM snapshots - wrong devicename in /proc/mounts
Hi, using btrfs with LVM snapshots seems to be confusing /proc/mounts After mounting a snapshot of an original filesystem, the devicename of the original filesystem is overwritten with that of the snapshot in /proc/mounts. Steps to reproduce: arnd@kallisto:/mnt$ sudo mount /dev/vg0/original /mnt/original [ 107.041432] device fsid 5c3e8ca2-da56-4ade-9fef-103a6a8a70c2 devid 1 transid 4 /dev/mapper/vg0-original [ 107.044691] btrfs: no dev_stats entry found for device /dev/mapper/vg0-original (devid 1) (OK on first mount after mkfs) arnd@kallisto:/mnt$ cat /proc/mounts | grep /mnt /dev/mapper/vg0-original /mnt/original btrfs rw,relatime,ssd,space_cache 0 0 arnd@kallisto:/mnt$ sudo lvcreate -L 10M --snap --name snapshot /dev/vg0/original arnd@kallisto:/mnt$ sudo mount /dev/vg0/testsnap /mnt/testsnap [ 215.432281] device fsid 5c3e8ca2-da56-4ade-9fef-103a6a8a70c2 devid 1 transid 4 /dev/mapper/vg0-testsnap arnd@kallisto:/mnt$ cat /proc/mounts | grep /mnt /dev/mapper/vg0-testsnap /mnt/original btrfs rw,relatime,ssd,space_cache 0 0 /dev/mapper/vg0-testsnap /mnt/testsnap btrfs rw,relatime,ssd,space_cache 0 0 arnd@kallisto:/mnt$ sudo umount /dev/vg0/testsnap arnd@kallisto:/mnt$ cat /proc/mounts | grep /mnt /dev/mapper/vg0-testsnap /mnt/original btrfs rw,relatime,ssd,space_cache 0 0 Best regards, Arnd -- 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.5.0-rc6: btrfs and LVM snapshots - wrong devicename in /proc/mounts
On Mon, Jul 9, 2012 at 4:22 PM, Arnd Hannemann a...@arndnet.de wrote: Hi, using btrfs with LVM snapshots seems to be confusing /proc/mounts After mounting a snapshot of an original filesystem, the devicename of the original filesystem is overwritten with that of the snapshot in /proc/mounts. If the lvm snapshot is visible to btrfs (i.e., btrfs dev scan), it will appear as another device which belongs to the original filesystem with a duplicate devid. This might result in bad things happening, or possibly just hilarity. You have a backup that isn't just an lvm snapshot, right? -- 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
kernel BUG at fs/btrfs/extent_io.c:1893!
Hi, I have this problem after trying to run btrfsck. I have new 11 HDDs WD 2tb, on two RAID controllers Arch Linux, latest kernel. What I was doing was copying and reading multiple data at the same time After getting I/O errors while trying to access through samba and while trying to run a VM with files stored on volume, I ran a btrfsck but it failed. [ 7155.485832] [ cut here ] [ 7155.486210] kernel BUG at fs/btrfs/extent_io.c:1893! [ 7155.486575] invalid opcode: [#1] PREEMPT SMP [ 7155.486965] CPU 2 [ 7155.486975] Modules linked in: nfnetlink_log nfnetlink hwmon_vid reiserfs btrfs zlib_deflate libcrc32c microcode ghash_clmulni_intel cryptd cx22702 cx88_dvb videobuf_dvb cx88_vp3054_i2c dvb_core rc_winfast tuner_simple tuner_types eeepc_wmi asus_wmi pci_hotplug tuner cx88_alsa snd_pcm snd_page_alloc snd_timer snd i915 drm_kms_helper cx8802 cx8800 cx88xx tveeprom btcx_risc videobuf_dma_sg mei(C) i2c_i801 drm intel_agp soundcore i2c_algo_bit videobuf_core v4l2_common e1000e videodev media rc_core i2c_core iTCO_wdt iTCO_vendor_support button acpi_cpufreq mperf processor pcspkr fan video thermal sparse_keymap rfkill coretemp intel_gtt wmi evdev vboxnetflt(O) crc32c_intel vboxdrv(O) ext4 crc16 jbd2 mbcache usbhid hid sd_mod mptsas scsi_transport_sas mptscsih mptbase ahci libahci libata xhci_hcd ehci_hcd scsi_mod usbcore usb_common [ 7155.490485] [ 7155.491187] Pid: 2549, comm: btrfs-delayed-m Tainted: G C O 3.4.4-2-ARCH #1 System manufacturer System Product Name/P8Z68-V LX [ 7155.491976] RIP: 0010:[a05f3a0f] [a05f3a0f] repair_io_failure+0x17f/0x1c0 [btrfs] [ 7155.492849] RSP: 0018:8803e5a4b740 EFLAGS: 00010246 [ 7155.493679] RAX: 8803e5a4b770 RBX: 023f77d8 RCX: 023f77d8 [ 7155.494536] RDX: 1000 RSI: 023f77d8 RDI: 8803fa4a0108 [ 7155.495410] RBP: 8803e5a4b7b0 R08: ea000f21d400 R09: [ 7155.496301] R10: R11: 0001 R12: 1000 [ 7155.497206] R13: ea000f21d400 R14: 8803fa4a0108 R15: [ 7155.498128] FS: () GS:88041f30() knlGS: [ 7155.499096] CS: 0010 DS: ES: CR0: 8005003b [ 7155.500062] CR2: 7f3ea3ee7000 CR3: 0180b000 CR4: 000427e0 [ 7155.501059] DR0: DR1: DR2: [ 7155.502073] DR3: DR6: 0ff0 DR7: 0400 [ 7155.503103] Process btrfs-delayed-m (pid: 2549, threadinfo 8803e5a4a000, task 880406bb7710) [ 7155.504168] Stack: [ 7155.505234] 8803e5a4b740 023f77d8 [ 7155.506354] 8803e5a4b770 8803e5a4b770 [ 7155.507493] 88030001 023f77d8 8803fa4a0108 [ 7155.508663] Call Trace: [ 7155.509822] [a05f43b2] repair_eb_io_failure+0x82/0xb0 [btrfs] [ 7155.511018] [a05ca362] btree_read_extent_buffer_pages.constprop.111+0x112/0x120 [btrfs] [ 7155.512249] [a05cab2a] read_tree_block+0x3a/0x50 [btrfs] [ 7155.513491] [a05b05d3] read_block_for_search.isra.32+0x203/0x3d0 [btrfs] [ 7155.514761] [a05afceb] ? generic_bin_search.constprop.34+0x6b/0x180 [btrfs] [ 7155.516046] [a05ac5a9] ? unlock_up+0x159/0x180 [btrfs] [ 7155.517344] [a05b29fc] btrfs_search_slot+0x3ec/0x900 [btrfs] [ 7155.518662] [a05b7ef3] lookup_inline_extent_backref+0xa3/0x470 [btrfs] [ 7155.520001] [a05b8d83] insert_inline_extent_backref+0x63/0x100 [btrfs] [ 7155.521342] [81159acf] ? kmem_cache_alloc+0x13f/0x150 [ 7155.522703] [a05b9f29] ? __btrfs_free_extent+0x229/0x7b0 [btrfs] [ 7155.524083] [a05b8ec1] __btrfs_inc_extent_ref+0xa1/0x1f0 [btrfs] [ 7155.525481] [a05becc8] run_clustered_refs+0x5f8/0xa00 [btrfs] [ 7155.526891] [a05afceb] ? generic_bin_search.constprop.34+0x6b/0x180 [btrfs] [ 7155.528330] [a05b5b25] ? __find_space_info+0x85/0xa0 [btrfs] [ 7155.529781] [a05bf245] btrfs_run_delayed_refs+0x175/0x450 [btrfs] [ 7155.531254] [a05b5e1c] ? block_rsv_release_bytes+0xec/0x1b0 [btrfs] [ 7155.532718] [814675ae] ? __mutex_lock_slowpath+0x24e/0x340 [ 7155.534153] [a05d0e9f] __btrfs_end_transaction+0x9f/0x350 [btrfs] [ 7155.535560] [a05d1168] btrfs_end_transaction_dmeta+0x18/0x20 [btrfs] [ 7155.536986] [a061f49a] btrfs_async_run_delayed_node_done+0x16a/0x1b0 [btrfs] [ 7155.538437] [a060167d] worker_loop+0x13d/0x570 [btrfs] [ 7155.539892] [a0601540] ? btrfs_queue_worker+0x320/0x320 [btrfs] [ 7155.541358] [810731d3] kthread+0x93/0xa0 [ 7155.542831] [8146bbe4] kernel_thread_helper+0x4/0x10 [ 7155.544314] [81073140] ? kthread_freezable_should_stop+0x70/0x70 [ 7155.545819] [8146bbe0] ? gs_change+0x13/0x13 [ 7155.547301] Code: 68 f4 ba e0 b8 fb ff ff
[PATCH] Btrfs: kill free_space pointer from inode structure
Inodes always allocate free space with BTRFS_BLOCK_GROUP_DATA type,
which means every inode has the same BTRFS_I(inode)-free_space pointer.
This shrinks struct btrfs_inode by 4 bytes (or 8 bytes on 64 bits).
Signed-off-by: Li Zefan lize...@huawei.com
---
fs/btrfs/btrfs_inode.h |3 ---
fs/btrfs/ctree.h |3 ++-
fs/btrfs/extent-tree.c | 20
fs/btrfs/inode.c |3 ---
4 files changed, 10 insertions(+), 19 deletions(-)
diff --git a/fs/btrfs/btrfs_inode.h b/fs/btrfs/btrfs_inode.h
index 12394a9..0b18b74 100644
--- a/fs/btrfs/btrfs_inode.h
+++ b/fs/btrfs/btrfs_inode.h
@@ -87,9 +87,6 @@ struct btrfs_inode {
/* node for the red-black tree that links inodes in subvolume root */
struct rb_node rb_node;
- /* the space_info for where this inode's data allocations are done */
- struct btrfs_space_info *space_info;
-
unsigned long runtime_flags;
/* full 64 bit generation number, struct vfs_inode doesn't have a big
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index fa5c45b..6761490 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -1240,6 +1240,8 @@ struct btrfs_fs_info {
*/
struct list_head space_info;
+ struct btrfs_space_info *data_sinfo;
+
struct reloc_control *reloc_ctl;
spinlock_t delalloc_lock;
@@ -2607,7 +2609,6 @@ int btrfs_remove_block_group(struct btrfs_trans_handle
*trans,
struct btrfs_root *root, u64 group_start);
u64 btrfs_reduce_alloc_profile(struct btrfs_root *root, u64 flags);
u64 btrfs_get_alloc_profile(struct btrfs_root *root, int data);
-void btrfs_set_inode_space_info(struct btrfs_root *root, struct inode *ionde);
void btrfs_clear_space_info_full(struct btrfs_fs_info *info);
int btrfs_check_data_free_space(struct inode *inode, u64 bytes);
void btrfs_free_reserved_data_space(struct inode *inode, u64 bytes);
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index bbab3ff..b1336f5 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -3133,6 +3133,8 @@ static int update_space_info(struct btrfs_fs_info *info,
u64 flags,
init_waitqueue_head(found-wait);
*space_info = found;
list_add_rcu(found-list, info-space_info);
+ if (flags BTRFS_BLOCK_GROUP_DATA)
+ info-data_sinfo = found;
return 0;
}
@@ -3262,12 +3264,6 @@ u64 btrfs_get_alloc_profile(struct btrfs_root *root, int
data)
return get_alloc_profile(root, flags);
}
-void btrfs_set_inode_space_info(struct btrfs_root *root, struct inode *inode)
-{
- BTRFS_I(inode)-space_info = __find_space_info(root-fs_info,
- BTRFS_BLOCK_GROUP_DATA);
-}
-
/*
* This will check the space that the inode allocates from to make sure we have
* enough space for bytes.
@@ -3276,6 +3272,7 @@ int btrfs_check_data_free_space(struct inode *inode, u64
bytes)
{
struct btrfs_space_info *data_sinfo;
struct btrfs_root *root = BTRFS_I(inode)-root;
+ struct btrfs_fs_info *fs_info = root-fs_info;
u64 used;
int ret = 0, committed = 0, alloc_chunk = 1;
@@ -3288,7 +3285,7 @@ int btrfs_check_data_free_space(struct inode *inode, u64
bytes)
committed = 1;
}
- data_sinfo = BTRFS_I(inode)-space_info;
+ data_sinfo = fs_info-data_sinfo;
if (!data_sinfo)
goto alloc;
@@ -3329,10 +3326,9 @@ alloc:
goto commit_trans;
}
- if (!data_sinfo) {
- btrfs_set_inode_space_info(root, inode);
- data_sinfo = BTRFS_I(inode)-space_info;
- }
+ if (!data_sinfo)
+ data_sinfo = fs_info-data_sinfo;
+
goto again;
}
@@ -3379,7 +3375,7 @@ void btrfs_free_reserved_data_space(struct inode *inode,
u64 bytes)
/* make sure bytes are sectorsize aligned */
bytes = (bytes + root-sectorsize - 1) ~((u64)root-sectorsize - 1);
- data_sinfo = BTRFS_I(inode)-space_info;
+ data_sinfo = root-fs_info-data_sinfo;
spin_lock(data_sinfo-lock);
data_sinfo-bytes_may_use -= bytes;
trace_btrfs_space_reservation(root-fs_info, space_info,
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 0d507e6..b189dd8 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -4077,7 +4077,6 @@ static int btrfs_init_locked_inode(struct inode *inode,
void *p)
struct btrfs_iget_args *args = p;
inode-i_ino = args-ino;
BTRFS_I(inode)-root = args-root;
- btrfs_set_inode_space_info(args-root, inode);
return 0;
}
@@ -4662,7 +4661,6 @@ static struct inode *btrfs_new_inode(struct
btrfs_trans_handle *trans,
BTRFS_I(inode)-root = root;
BTRFS_I(inode)-generation =
[PATCH] Btrfs: rewrite BTRFS_SETGET_FUNCS
BTRFS_SETGET_FUNCS macro is used to generate btrfs_set_foo() and
btrfs_foo() functions, which read and write specific fields in the
extent buffer.
The total number of set/get functions is ~200, but in fact we only
need 8 functions: 2 for u8 field, 2 for u16, 2 for u32 and 2 for u64.
It results in redunction of ~37K bytes.
textdata bss dec hex filename
629661 12489 216 642366 9cd3e fs/btrfs/btrfs.o.orig
592637 12489 216 605342 93c9e fs/btrfs/btrfs.o
Signed-off-by: Li Zefan lize...@huawei.com
---
fs/btrfs/ctree.h| 53 +++--
fs/btrfs/struct-funcs.c | 196 ---
2 files changed, 146 insertions(+), 103 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 6761490..e262362 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -1623,13 +1623,54 @@ static inline void btrfs_init_map_token (struct
btrfs_map_token *token)
offsetof(type, member), \
sizeof(((type *)0)-member)))
-#ifndef BTRFS_SETGET_FUNCS
+#define DECLARE_BTRFS_SETGET_BITS(bits)
\
+u##bits btrfs_get_token_##bits(struct extent_buffer *eb, void *ptr,\
+ unsigned long off, \
+ struct btrfs_map_token *token); \
+void btrfs_set_token_##bits(struct extent_buffer *eb, void *ptr, \
+ unsigned long off, u##bits val, \
+ struct btrfs_map_token *token); \
+static inline u##bits btrfs_get_##bits(struct extent_buffer *eb, void *ptr, \
+ unsigned long off) \
+{ \
+ return btrfs_get_token_##bits(eb, ptr, off, NULL); \
+} \
+static inline void btrfs_set_##bits(struct extent_buffer *eb, void *ptr, \
+ unsigned long off, u##bits val) \
+{ \
+ btrfs_set_token_##bits(eb, ptr, off, val, NULL);\
+}
+
+DECLARE_BTRFS_SETGET_BITS(8)
+DECLARE_BTRFS_SETGET_BITS(16)
+DECLARE_BTRFS_SETGET_BITS(32)
+DECLARE_BTRFS_SETGET_BITS(64)
+
#define BTRFS_SETGET_FUNCS(name, type, member, bits) \
-u##bits btrfs_##name(struct extent_buffer *eb, type *s); \
-u##bits btrfs_token_##name(struct extent_buffer *eb, type *s, struct
btrfs_map_token *token); \
-void btrfs_set_token_##name(struct extent_buffer *eb, type *s, u##bits val,
struct btrfs_map_token *token);\
-void btrfs_set_##name(struct extent_buffer *eb, type *s, u##bits val);
-#endif
+static inline u##bits btrfs_##name(struct extent_buffer *eb, type *s) \
+{ \
+ BUILD_BUG_ON(sizeof(u##bits) != sizeof(((type *)0))-member); \
+ return btrfs_get_##bits(eb, s, offsetof(type, member)); \
+} \
+static inline void btrfs_set_##name(struct extent_buffer *eb, type *s, \
+ u##bits val)\
+{ \
+ BUILD_BUG_ON(sizeof(u##bits) != sizeof(((type *)0))-member); \
+ btrfs_set_##bits(eb, s, offsetof(type, member), val); \
+} \
+static inline u##bits btrfs_token_##name(struct extent_buffer *eb, type *s, \
+struct btrfs_map_token *token) \
+{ \
+ BUILD_BUG_ON(sizeof(u##bits) != sizeof(((type *)0))-member); \
+ return btrfs_get_token_##bits(eb, s, offsetof(type, member), token); \
+} \
+static inline void btrfs_set_token_##name(struct extent_buffer *eb,\
+ type *s, u##bits val, \
+ struct btrfs_map_token *token) \
+{ \
+ BUILD_BUG_ON(sizeof(u##bits) != sizeof(((type *)0))-member); \
+ btrfs_set_token_##bits(eb, s, offsetof(type, member), val, token); \
+}
#define BTRFS_SETGET_HEADER_FUNCS(name, type, member, bits)\
static inline u##bits btrfs_##name(struct extent_buffer *eb) \
diff --git a/fs/btrfs/struct-funcs.c b/fs/btrfs/struct-funcs.c
index c6ffa58..1f4ede9 100644
--- a/fs/btrfs/struct-funcs.c
+++ b/fs/btrfs/struct-funcs.c
@@ -17,15 +17,27 @@
*/
#include linux/highmem.h
+#include asm/unaligned.h
-/* this is some
Re: btrfs GPF in read_extent_buffer() while scrubbing with kernel 3.4.2
On Mon, Jul 09, 2012 at 11:05:47AM +0200, Arne Jansen wrote: * Just before the crash: btrfs: invalid parameters for read_extent_buffer: start (32771) eb-len (32768). eb start is 2261163409408, level 100, generation 4412718571037421157, nritems 538968254. len param 17. debug 2/989/538968254/4412718571037421157/0x0/0/0x0/0x0 At a first glance: the generation converted to ascii is: ent() ==, so someone is patching the memory with ascii text, possibly C source. It might be interesting to dump the full contents of the eb, to get a clue on the source of the data. I changed the code to dump the contents of the eb struct at the point where that error (btrfs: invalid parameters...) is printed, at the checksum mismatch 4 site and at the node seems invalid now site. Now I have a big log of 1795 corrupted ebs. So far nothing that looks remotely like ascii text, though. But I have two different versions of the eb that caused that warning, a less corrupted one and a more corrupted one: btrfs: --- start eb contents at 8801b13cc4c8 --- btrfs: 8801b13cc4c8: 00 80 e4 66 09 02 00 00 00 80 00 00 00 00 00 00 ...f btrfs: 8801b13cc4d8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 btrfs: 8801b13cc4e8: 20 00 00 00 00 00 00 00 30 00 d7 10 02 88 ff ff ...0... btrfs: 8801b13cc4f8: 02 02 00 00 03 00 00 00 06 00 00 00 00 00 00 00 btrfs: 8801b13cc508: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 btrfs: 8801b13cc518: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 btrfs: 8801b13cc528: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 btrfs: 8801b13cc538: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 btrfs: 8801b13cc548: 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 btrfs: 8801b13cc558: 58 c5 3c b1 01 88 ff ff 58 c5 3c b1 01 88 ff ff X..X.. btrfs: 8801b13cc568: 00 00 00 00 00 00 00 00 70 c5 3c b1 01 88 ff ff p.. btrfs: 8801b13cc578: 70 c5 3c b1 01 88 ff ff 00 00 00 00 00 00 00 00 p.. btrfs: 8801b13cc588: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 btrfs: 8801b13cc598: 80 5f 9a 06 00 ea ff ff 00 86 9b 06 00 ea ff ff ._.. btrfs: 8801b13cc5a8: 40 4c 9a 06 00 ea ff ff 80 66 9a 06 00 ea ff ff @L...f.. btrfs: 8801b13cc5b8: 80 eb 9b 06 00 ea ff ff 40 05 a2 06 00 ea ff ff @... btrfs: 8801b13cc5c8: 40 e1 9b 06 00 ea ff ff 80 c4 9c 06 00 ea ff ff @... btrfs: 8801b13cc5d8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 btrfs: 8801b13cc5e8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 btrfs: 8801b13cc5f8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 btrfs: 8801b13cc608: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 btrfs: 8801b13cc618: 98 c5 3c b1 01 88 ff ff 00 00 00 00 00 00 00 00 ... btrfs: 8801b13cc628: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 btrfs: 8801b13cc638: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 btrfs: 8801b13cc648: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 btrfs: 8801b13cc658: 00 00 00 00 00 00 00 00 btrfs: --- end eb contents at 8801b13cc4c8 --- btrfs: dm-6 checksum verify failed on 2239404212224 wanted B5F632BC found 3579FB59 level 160 btrfs: node seems invalid now. checksum ok = 1 btrfs: --- start eb contents at 8801b13cc4c8 --- [... identical dump to above ...] btrfs: --- end eb contents at 8801b13cc4c8 --- btrfs: invalid parameters for read_extent_buffer: start (32771) eb-len (32768). eb start is 2239404212224, level 160, generation 4716553384049587249, nritems 295705211. len param 17. debug 2/989/295705211/4716553384049587249/0x0/0/0x0/0x0 btrfs: --- start eb contents at 8801b13cc4c8 --- btrfs: 8801b13cc4c8: 00 80 e4 66 09 02 00 00 00 80 00 00 00 00 00 00 ...f btrfs: 8801b13cc4d8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 btrfs: 8801b13cc4e8: 20 00 00 00 00 00 00 00 30 00 d7 10 02 88 ff ff ...0... btrfs: 8801b13cc4f8: 02 02 00 00 03 00 00 00 06 00 00 00 00 00 00 00 btrfs: 8801b13cc508: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 btrfs: 8801b13cc518: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 btrfs: 8801b13cc528: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 btrfs: 8801b13cc538: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 btrfs: 8801b13cc548: 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 btrfs: 8801b13cc558: 58 c5 3c b1
Re: [PATCH] Btrfs: Add code to support file creation time.
On 2012/7/5 9:52, Alexander Block wrote: On Thu, Jul 5, 2012 at 3:07 AM, Li Zefan lize...@huawei.com wrote: On 2012/7/4 19:04, Alexander Block wrote: On Wed, Jul 4, 2012 at 9:56 AM, Li Zefan lize...@huawei.com wrote: On 2012/7/4 15:18, chandan r wrote: This patch adds a new member to the 'struct btrfs_inode' structure to hold the file creation time. Well, how do users use this file creation time? There's no syscall and there's no ioctl that exports this information. That xstat syscall hasn't been accepted, so you can revise and repost the patch when you see it happens. In my opinion we should still include this patch. Currently, otime is never even initialized, having undefined values. If it ever gets possible to access otime, we would at least have some inodes with valid otime fields. otime (on disk) is initialized to 0, not some undefined value. But yeah, your point makes some sense, that with this patch we can access valid otime in an old filesystem once we update to a new kernel which has otime support. This is true for the inode items found in the root tree. But the inode items found in the filesystem trees are not initialized at all. I did a fast check by adding printing of the otime field in btrfs-debug-tree...and every inode's otime looks random. btrfs_new_inode uses btrfs_insert_empty_items which does not zero the new item, then fill_inode_item is used to initialize the fields and there otime is missing. That's bad.. -- 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
