Re: backref for an extent not found in send_root (!backref_ctx-found_itself)

2013-02-19 Thread Jan Schmidt 
Hi Alex,

On Tue, February 19, 2013 at 08:58 (+0100), Alex Lyakas wrote:
 any luck reproducing this?

Just yesterday, yes. I was busy doing non-btrfs things, I've got an idea about
the problem, but unfortunately I'm again busy doing other things right now. That
will hopefully be the last distraction before fixing this.

Thanks again for your good reproducer!
-Jan
--
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: Integration branch of btrfs-progs 2013-02

2013-02-19 Thread David Sterba 
On Tue, Feb 12, 2013 at 07:35:31PM -0800, Filipe Brandenburger wrote:
 I really have concerns about the libification, in particular this commit:
 
 6fc8b21 btrfs-progs: libify some parts of btrfs-progs
[...]
 I really don't think that all those headers should be exposed to the 
 userspace.
 
 I think, to do it right, there should be a single or a few header
 files, like /usr/include/btrfs.h or /usr/include/libbtrfs.h or
 /usr/include/btrfs/xyz.h, that export only the parts that are really
 necessary for an application that wants to use libbtrfs. Does it
 really make sense to have btrfs-progs expose things like ctree.h or
 crc32c.h or even list.h to userspace?!
[...]

For the record and public status of the libify patches: after the
discussion on IRC a few days ago there is more work need to clean and
finalize the header interfaces so that two currently proposed and future
users of the library are satisfied.

For that reason I'll not add libify patches into the integration branch
directly, but keep it in a separate branch until all sides are ok, so
that the integration branch is a relatively stable codebase for fixes
and minor updates.

That's my view of the situation, feel free to correct or update the bits
I might have missed.


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

Integration branch of btrfs-progs 2013-02-19

2013-02-19 Thread David Sterba 
Hi,

a set of updates and fixes, plus two libify patches left out for
now (*):

btrfs-progs: libify some parts of btrfs-progs
btrfs-progs: don't link binaries to a dynamic library

* http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg22293.html

In the near-todo are the label patches as the kernel functionality is
going to land in 3.9, otherwise I'm still processing the remaining old
patches and will pick up recent fixes eventually.

  git://repo.or.cz/btrfs-progs-unstable/devel.git integration-20130219


Thanks for testing,
david

---
Shortlog (only new patches on top of previous integration):

Eric Sandeen (1):
  btrfs-progs: require mkfs -f force option to overwrite filesystem or 
partition table

Liu Bo (1):
  Btrfs-progs: fix segmentation fault of 'btrfs-debug-tree -e'

Mark Fasheh (1):
  btrfs-progs: Fix pointer math in __ino_to_path_fd

Tsutomu Itoh (1):
  Btrfs-progs: check out if the swap device
--
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

[RFC][PATCH] btrfs-progs: mkfs: add -O option to specify fs features

2013-02-19 Thread David Sterba 
Extend mkfs options to specify optional or potentially backwards
incompatible features. Use it for extended references.

Signed-off-by: David Sterba dste...@suse.cz
---

The RFC is for the option name, as there does not seem to be a common name
amongst other mkfses.


 man/mkfs.btrfs.8.in |  7 +++
 mkfs.c  | 14 --
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/man/mkfs.btrfs.8.in b/man/mkfs.btrfs.8.in
index 41163e0..5ff4e2c 100644
--- a/man/mkfs.btrfs.8.in
+++ b/man/mkfs.btrfs.8.in
@@ -15,6 +15,7 @@ mkfs.btrfs \- create a btrfs filesystem
 [ \fB\-s\fP\fI sectorsize\fP ]
 [ \fB\-r\fP\fI rootdir\fP ]
 [ \fB\-K\fP ]
+[ \fB\-O\fP\fI feature1,feature2,...\fP ]
 [ \fB\-h\fP ]
 [ \fB\-V\fP ]
 \fI device\fP [ \fIdevice ...\fP ]
@@ -76,6 +77,12 @@ Specify a directory to copy into the newly created fs.
 \fB\-K\fR, \fB\-\-nodiscard \fR
 Do not perform whole device TRIM operation by default.
 .TP
+\fB\-O\fR, \fB\-\-features \fIfeature1,feature2,...\fR
+A list of filesystem features turned on at mkfs time. Not all features are
+supported by old kernels.
+
+extref - allow creating more hardlinks per file (the upper limit is 65535)
+.TP
 \fB\-V\fR, \fB\-\-version\fR
 Print the \fBmkfs.btrfs\fP version and exit.
 .SH UNIT
diff --git a/mkfs.c b/mkfs.c
index 5ece186..dd1e317 100644
--- a/mkfs.c
+++ b/mkfs.c
@@ -335,6 +335,7 @@ static void print_usage(void)
fprintf(stderr, \t -s --sectorsize min block allocation\n);
fprintf(stderr, \t -r --rootdir the source directory\n);
fprintf(stderr, \t -K --nodiscard do not perform whole device TRIM\n);
+   fprintf(stderr, \t -O --features coma separated list of filesystem 
features\n);
fprintf(stderr, \t -V --version print the mkfs.btrfs version and 
exit\n);
fprintf(stderr, %s\n, BTRFS_BUILD_VERSION);
exit(1);
@@ -395,6 +396,7 @@ static struct option long_options[] = {
{ version, 0, NULL, 'V' },
{ rootdir, 1, NULL, 'r' },
{ nodiscard, 0, NULL, 'K' },
+   { features, 0, NULL, 'O' },
{ 0, 0, 0, 0}
 };
 
@@ -1376,10 +1378,11 @@ int main(int ac, char **av)
char *pretty_buf;
struct btrfs_super_block *super;
u64 flags;
+   char *features = strdup();
 
while(1) {
int c;
-   c = getopt_long(ac, av, A:b:fl:n:s:m:d:L:r:VMK, long_options,
+   c = getopt_long(ac, av, A:b:fl:n:s:m:d:L:O:r:VMK, 
long_options,
option_index);
if (c  0)
break;
@@ -1409,6 +1412,10 @@ int main(int ac, char **av)
case 'M':
mixed = 1;
break;
+   case 'O':
+   free(features);
+   features = strdup(optarg);
+   break;
case 's':
sectorsize = parse_size(optarg);
break;
@@ -1652,7 +1659,10 @@ raid_groups:
 
super = root-fs_info-super_copy;
flags = btrfs_super_incompat_flags(super);
-   flags |= BTRFS_FEATURE_INCOMPAT_EXTENDED_IREF;
+   if (strstr(features, extref) == 0) {
+   fprintf(stderr, Turning ON incompat feature: extref (increased 
hardlink limit per file)\n);
+   flags |= BTRFS_FEATURE_INCOMPAT_EXTENDED_IREF;
+   }
 
if (mixed)
flags |= BTRFS_FEATURE_INCOMPAT_MIXED_GROUPS;
-- 
1.8.0.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: btrfsck: extent-tree.c:2549: btrfs_reserve_extent: Assertion `!(ret)' failed.

2013-02-19 Thread Richard Cooper 

On 3 Jan 2013, at 12:26, Richard Cooper wrote:
 Hi All,
 
 I'm trying to repair a broken fs using btrfsck and am hitting a failed 
 assertion. I'd appreciate any suggestions for what to do next. Is there any 
 thing I can do to help fix this bug? Any other information from my FS which 
 would help? If the FS could be salvaged that would be a bonus, but I'm more 
 interested in providing a useful bug report before wiping the disk.

After this error I reformatted and started again. A few days ago I hit exactly 
the same error in btrfsck again. Is it useful for me to report the same errors 
again? Would it make more sense for me to submit them to 
https://bugzilla.kernel.org? Is that tracker appropriate for btrfs-progs 
related bugs?

My versions are:
- OS - CentOS 6.3
- Kernel -  3.7.8-1 from http://elrepo.org/tiki/kernel-ml 
- btrfs-progs - v0.20-rc1-56-g6cd836d. Built from 
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git

# ./btrfs-progs/btrfs fi show /dev/md4
Label: none  uuid: fecad98e-63e8-47b7-9bc1-5d9351f15e76
Total devices 1 FS bytes used 702.22GB
devid1 size 16.36TB used 723.04GB path /dev/md4

Btrfs v0.20-rc1-56-g6cd836d

# ./btrfsck --repair /dev/md4 
enabling repair mode
checking extents
incorrect offsets 2539 133611
bad block 694804008960
bad key ordering 26 27
bad block 710147256320
bad key ordering 29 30
bad block 710793940992
ref mismatch on [506097786880 8192] extent item 1, found 0
btrfsck: extent-tree.c:2549: btrfs_reserve_extent: Assertion `!(ret)' failed.
Aborted
# echo $?
134

If i run btrfsck in non-repair mode I get:

# ./btrfsck /dev/md4 
checking extents
incorrect offsets 2539 133611
bad block 694804008960
bad key ordering 26 27
bad block 710147256320
bad key ordering 29 30
bad block 710793940992
ref mismatch on [506097786880 8192] extent item 1, found 0
Incorrect local backref count on 506097786880 root 257 owner 6201018 offset 0 
found 0 wanted 1 back 0x72966380
backpointer mismatch on [506097786880 8192]
owner ref check failed [506097786880 8192]
ref mismatch on [506097795072 8192] extent item 1, found 0
Incorrect local backref count on 506097795072 root 257 owner 6201019 offset 0 
found 0 wanted 1 back 0x72966460
backpointer mismatch on [506097795072 8192]
owner ref check failed [506097795072 8192]
ref mismatch on [506097803264 8192] extent item 1, found 0
Incorrect local backref count on 506097803264 root 257 owner 6201021 offset 0 
found 0 wanted 1 back 0x72966540
backpointer mismatch on [506097803264 8192]
owner ref check failed [506097803264 8192]
ref mismatch on [506097811456 8192] extent item 1, found 0
Incorrect local backref count on 506097811456 root 257 owner 6201022 offset 0 
found 0 wanted 1 back 0x72966620
backpointer mismatch on [506097811456 8192]
owner ref check failed [506097811456 8192]
ref mismatch on [686802194432 20480] extent item 1, found 0
Incorrect local backref count on 686802194432 root 257 owner 8037960 offset 0 
found 0 wanted 1 back 0x82c1e2a0
backpointer mismatch on [686802194432 20480]
owner ref check failed [686802194432 20480]
ref mismatch on [686802214912 20480] extent item 1, found 0
Incorrect local backref count on 686802214912 root 257 owner 8037961 offset 0 
found 0 wanted 1 back 0x82c1e380
backpointer mismatch on [686802214912 20480]
owner ref check failed [686802214912 20480]
ref mismatch on [686802235392 20480] extent item 1, found 0
Incorrect local backref count on 686802235392 root 257 owner 8037962 offset 0 
found 0 wanted 1 back 0x82c1e460
backpointer mismatch on [686802235392 20480]
owner ref check failed [686802235392 20480]
ref mismatch on [686802255872 20480] extent item 1, found 0
Incorrect local backref count on 686802255872 root 257 owner 8037963 offset 0 
found 0 wanted 1 back 0x82c1e540
backpointer mismatch on [686802255872 20480]
owner ref check failed [686802255872 20480]
ref mismatch on [686802276352 20480] extent item 1, found 0
Incorrect local backref count on 686802276352 root 257 owner 8037964 offset 0 
found 0 wanted 1 back 0x82c1e620
backpointer mismatch on [686802276352 20480]
owner ref check failed [686802276352 20480]
ref mismatch on [686802296832 20480] extent item 1, found 0
Incorrect local backref count on 686802296832 root 257 owner 8037965 offset 0 
found 0 wanted 1 back 0x82c1e700
backpointer mismatch on [686802296832 20480]
owner ref check failed [686802296832 20480]
ref mismatch on [686802317312 20480] extent item 1, found 0
Incorrect local backref count on 686802317312 root 257 owner 8037966 offset 0 
found 0 wanted 1 back 0x82c1e7e0
backpointer mismatch on [686802317312 20480]
owner ref check failed [686802317312 20480]
owner ref check failed [694804008960 4096]
owner ref check failed [710147256320 4096]
owner ref check failed [710793940992 4096]
Errors found in extent allocation tree
checking fs roots
root 257 inode 6292865 errors 400
root 257 inode 6292867 errors 400
found 754001297408 bytes used err is 1
total csum bytes: 718173168
total tree bytes:

Re: [RFC][PATCH] btrfs-progs: mkfs: add -O option to specify fs features

2013-02-19 Thread Eric Sandeen 
On 2/19/13 5:16 AM, David Sterba wrote:
 Extend mkfs options to specify optional or potentially backwards
 incompatible features. Use it for extended references.
 
 Signed-off-by: David Sterba dste...@suse.cz
 ---
 
 The RFC is for the option name, as there does not seem to be a common name
 amongst other mkfses.

What did you find when looking?

xfsprogs doesn't really have a feature flag option per se; there are just block,
inode, size, log, data etc. options which may trigger some feature set.

e2fsprogs has the rather -O feature -E extended-options set, and darned if I 
could
tell you the difference ;)

but I think -O is the right option, unless you found other common mkfs's that
use something different.  When in doubt, e2fsprogs conventions probably win.  :)

-Eric

 
  man/mkfs.btrfs.8.in |  7 +++
  mkfs.c  | 14 --
  2 files changed, 19 insertions(+), 2 deletions(-)
 
 diff --git a/man/mkfs.btrfs.8.in b/man/mkfs.btrfs.8.in
 index 41163e0..5ff4e2c 100644
 --- a/man/mkfs.btrfs.8.in
 +++ b/man/mkfs.btrfs.8.in
 @@ -15,6 +15,7 @@ mkfs.btrfs \- create a btrfs filesystem
  [ \fB\-s\fP\fI sectorsize\fP ]
  [ \fB\-r\fP\fI rootdir\fP ]
  [ \fB\-K\fP ]
 +[ \fB\-O\fP\fI feature1,feature2,...\fP ]
  [ \fB\-h\fP ]
  [ \fB\-V\fP ]
  \fI device\fP [ \fIdevice ...\fP ]
 @@ -76,6 +77,12 @@ Specify a directory to copy into the newly created fs.
  \fB\-K\fR, \fB\-\-nodiscard \fR
  Do not perform whole device TRIM operation by default.
  .TP
 +\fB\-O\fR, \fB\-\-features \fIfeature1,feature2,...\fR
 +A list of filesystem features turned on at mkfs time. Not all features are
 +supported by old kernels.
 +
 +extref - allow creating more hardlinks per file (the upper limit is 65535)
 +.TP
  \fB\-V\fR, \fB\-\-version\fR
  Print the \fBmkfs.btrfs\fP version and exit.
  .SH UNIT
 diff --git a/mkfs.c b/mkfs.c
 index 5ece186..dd1e317 100644
 --- a/mkfs.c
 +++ b/mkfs.c
 @@ -335,6 +335,7 @@ static void print_usage(void)
   fprintf(stderr, \t -s --sectorsize min block allocation\n);
   fprintf(stderr, \t -r --rootdir the source directory\n);
   fprintf(stderr, \t -K --nodiscard do not perform whole device TRIM\n);
 + fprintf(stderr, \t -O --features coma separated list of filesystem 
 features\n);
   fprintf(stderr, \t -V --version print the mkfs.btrfs version and 
 exit\n);
   fprintf(stderr, %s\n, BTRFS_BUILD_VERSION);
   exit(1);
 @@ -395,6 +396,7 @@ static struct option long_options[] = {
   { version, 0, NULL, 'V' },
   { rootdir, 1, NULL, 'r' },
   { nodiscard, 0, NULL, 'K' },
 + { features, 0, NULL, 'O' },
   { 0, 0, 0, 0}
  };
  
 @@ -1376,10 +1378,11 @@ int main(int ac, char **av)
   char *pretty_buf;
   struct btrfs_super_block *super;
   u64 flags;
 + char *features = strdup();
  
   while(1) {
   int c;
 - c = getopt_long(ac, av, A:b:fl:n:s:m:d:L:r:VMK, long_options,
 + c = getopt_long(ac, av, A:b:fl:n:s:m:d:L:O:r:VMK, 
 long_options,
   option_index);
   if (c  0)
   break;
 @@ -1409,6 +1412,10 @@ int main(int ac, char **av)
   case 'M':
   mixed = 1;
   break;
 + case 'O':
 + free(features);
 + features = strdup(optarg);
 + break;
   case 's':
   sectorsize = parse_size(optarg);
   break;
 @@ -1652,7 +1659,10 @@ raid_groups:
  
   super = root-fs_info-super_copy;
   flags = btrfs_super_incompat_flags(super);
 - flags |= BTRFS_FEATURE_INCOMPAT_EXTENDED_IREF;
 + if (strstr(features, extref) == 0) {
 + fprintf(stderr, Turning ON incompat feature: extref (increased 
 hardlink limit per file)\n);
 + flags |= BTRFS_FEATURE_INCOMPAT_EXTENDED_IREF;
 + }
  
   if (mixed)
   flags |= BTRFS_FEATURE_INCOMPAT_MIXED_GROUPS;
 

--
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/8] Add some helpers to manage the strings allocation/deallocation.

2013-02-19 Thread Zach Brown 
 Of course, if after string_list_free() some dynamically allocated
 strings are used then bad things could happen.

Right.  So let's not make that even possible by not having the code at
all.

 Sorry I don't understand the differences between {leaked, scaled,
 raw}_string. Could you elaborate a bit ?

The code I saw returned an allocated string that the caller has to worry
about.  Crummy code just ignores the problem.  You added the global list
of strings to free at some point in the future.

I'm suggesting it not allocate at all so that there's nothing to free.

Instead of:

printf(%s, pretty(value));

char *pretty(u64 value) {
static char *units[] = { KB, MB, /* etc */ };
char *str = malloc(20); /*  should be 21 */
sprintf(str, %llu%s,
scale(value), units[scale_index(value));
global_list_stuff(str);
return str;
}

Do:

printf(%llu%s, scale(value), unit_string(value));

char *unit(u64 value)
{
static char *units[] = { KB, MB, /* etc */ };
return units[scale_index(value));
}

(all rough code, obviously)

Then there's nothing for the caller to worry about.

Right?

- z
--
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/8] Add some helpers to manage the strings allocation/deallocation.

2013-02-19 Thread Goffredo Baroncelli 
On 02/19/2013 06:21 PM, Zach Brown wrote:
 Of course, if after string_list_free() some dynamically allocated
 strings are used then bad things could happen.
 
 Right.  So let's not make that even possible by not having the code at
 all.
 
 Sorry I don't understand the differences between {leaked, scaled,
 raw}_string. Could you elaborate a bit ?
 
 The code I saw returned an allocated string that the caller has to worry
 about.  Crummy code just ignores the problem.  You added the global list
 of strings to free at some point in the future.
 
 I'm suggesting it not allocate at all so that there's nothing to free.
 
 Instead of:
 
   printf(%s, pretty(value));
 
   char *pretty(u64 value) {
   static char *units[] = { KB, MB, /* etc */ };
   char *str = malloc(20); /*  should be 21 */
   sprintf(str, %llu%s,
   scale(value), units[scale_index(value));
   global_list_stuff(str);
   return str;
   }
 
 Do:
 
   printf(%llu%s, scale(value), unit_string(value));
 
   char *unit(u64 value)
   {
   static char *units[] = { KB, MB, /* etc */ };
   return units[scale_index(value));
   }
 
 (all rough code, obviously)
 
 Then there's nothing for the caller to worry about.


Sorry but this is very dangerous and it leads to very subtle bug: what
happens if someone wrote:

printf(%d%s - %d%s\n, scale(123), unit_string(123),
scale(123), unit_string(456) );



 
 Right?
 
 - z
 


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5
--
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/8] Add some helpers to manage the strings allocation/deallocation.

2013-02-19 Thread Zach Brown 
 Sorry but this is very dangerous and it leads to very subtle bug: what
 happens if someone wrote:

very dangerous?  I disagree.

If you're worried about the value and units getting out of sync then you
offer some helper macros:

 printf(%d%s - %d%s\n, scale(123), unit_string(123),
   scale(123), unit_string(456) );

#define pty_fmt %llu%s
#define pty_arg(v) scale(v), unit_string(v)

printf(pty_fmt, pty_arg(v));

The kernel used to print ipv4 addresses like this before it grew its own
%pI4 format specifier.

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

Snapshot Cleaner not Working with inode_cache

2013-02-19 Thread Mitch Harder 
I've encountered an issue where the space from previously deleted
snapshots is not being freed up by the cleaner thread.

I'm only encountering this issue when I mount with the inode_cache option.

I've reproduced this on a 3.7.9 kernel merged with the latest
for-linus branch.  No additional patches are involved.  My testing
partition is 16 GB.

There is nothing in dmesg indicating any issues.

A simple manual test can reproduce the issue on my box

(1)  Format a fresh, scratch btrfs partition (it would probably work
with an existing test partition, but I always like to test things that
seem broken on a scratch partition).
(2)  Mount partition (my options are -o
compress-force=lzo,inode_cache).  My mount command was:
mount -o compress-force=lzo,inode_cache /dev/sda7 /mnt/benchmark/
(3)  Make a subvolume:  cd /mnt/device; btrfs su create test1
(4)  Untar kernel sources to the subvolume:  cd test1; tar -xpf
path/to/kernel/source/tarball
I believe anything you use to populate the subvolume is sufficient.
(5)  Make a note of the disk usage:  df -T /mnt/device
(6)  Remove the subvolume:  cd ..; btrfs su delete test1
(7)  Wait 2 minutes, and notice that the space has not been freed up.
I've waited much longer, but I forget the exact timeout on the cleaner
thread.
df -T /mnt/device

If I unmount and remount the partition with the same mount options,
the cleaner will begin to correctly free the space.

I've never used the inode_cache option before, so I'll try a few other
kernels to see if this is a regression.
--
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/8] Add some helpers to manage the strings allocation/deallocation.

2013-02-19 Thread Goffredo Baroncelli 
On 02/19/2013 06:59 PM, Zach Brown wrote:
 Sorry but this is very dangerous and it leads to very subtle bug: what
 happens if someone wrote:
 
 very dangerous?  I disagree.
 
 If you're worried about the value and units getting out of sync then you
 offer some helper macros:

No my complaint was related to another thing; but I was wrong. Anyway
your suggestion is not so easy applicable, and (IMHO) I don't see any
difficulty to remember to call string_list_free() only at the end of the
code.

 
 printf(%d%s - %d%s\n, scale(123), unit_string(123),
  scale(123), unit_string(456) );
 
   #define pty_fmt %llu%s
   #define pty_arg(v) scale(v), unit_string(v)
 
   printf(pty_fmt, pty_arg(v));
 
 The kernel used to print ipv4 addresses like this before it grew its own
 %pI4 format specifier.
 
 - z
 


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5
--
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/8] Add some helpers to manage the strings allocation/deallocation.

2013-02-19 Thread Zach Brown 
 No my complaint was related to another thing; but I was wrong. Anyway
 your suggestion is not so easy applicable, and (IMHO) I don't see any
 difficulty to remember to call string_list_free() only at the end of the
 code.

Understood, and I disagree.  It's simply not needed.

- z
--
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: define BTRFS_MAGIC as a u64 value

2013-02-19 Thread Zach Brown 
super.magic is an le64 but it's treated as an unterminated string when
compared against BTRFS_MAGIC which is defined as a string.  Instead
define BTRFS_MAGIC as a normal hex value and use endian helpers to
compare it to the super's magic.

I tested this by mounting an fs made before the change and made sure
that it didn't introduce sparse errors.  This matches a similar cleanup
that is pending in btrfs-progs.  David Sterba pointed out that we should
fix the kernel side as well :).

Signed-off-by: Zach Brown z...@redhat.com
---
 fs/btrfs/check-integrity.c | 3 +--
 fs/btrfs/ctree.h   | 2 +-
 fs/btrfs/disk-io.c | 6 ++
 fs/btrfs/volumes.c | 3 +--
 4 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/fs/btrfs/check-integrity.c b/fs/btrfs/check-integrity.c
index 11d47bf..18af6f4 100644
--- a/fs/btrfs/check-integrity.c
+++ b/fs/btrfs/check-integrity.c
@@ -813,8 +813,7 @@ static int btrfsic_process_superblock_dev_mirror(
(bh-b_data + (dev_bytenr  4095));
 
if (btrfs_super_bytenr(super_tmp) != dev_bytenr ||
-   strncmp((char *)((super_tmp-magic)), BTRFS_MAGIC,
-   sizeof(super_tmp-magic)) ||
+   super_tmp-magic != cpu_to_le64(BTRFS_MAGIC) ||
memcmp(device-uuid, super_tmp-dev_item.uuid, BTRFS_UUID_SIZE) ||
btrfs_super_nodesize(super_tmp) != state-metablock_size ||
btrfs_super_leafsize(super_tmp) != state-metablock_size ||
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 9f72ec8..8d88d1e 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -46,7 +46,7 @@ extern struct kmem_cache *btrfs_path_cachep;
 extern struct kmem_cache *btrfs_free_space_cachep;
 struct btrfs_ordered_sum;
 
-#define BTRFS_MAGIC _BHRfS_M
+#define BTRFS_MAGIC 0x4D5F53665248425FULL /* ascii _BHRfS_M, no null */
 
 #define BTRFS_MAX_MIRRORS 3
 
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 6baa77d..1d1ba22 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -2407,8 +2407,7 @@ int open_ctree(struct super_block *sb,
sb-s_blocksize = sectorsize;
sb-s_blocksize_bits = blksize_bits(sectorsize);
 
-   if (strncmp((char *)(disk_super-magic), BTRFS_MAGIC,
-   sizeof(disk_super-magic))) {
+   if (disk_super-magic != cpu_to_le64(BTRFS_MAGIC)) {
printk(KERN_INFO btrfs: valid FS not found on %s\n, sb-s_id);
goto fail_sb_buffer;
}
@@ -2815,8 +2814,7 @@ struct buffer_head *btrfs_read_dev_super(struct 
block_device *bdev)
 
super = (struct btrfs_super_block *)bh-b_data;
if (btrfs_super_bytenr(super) != bytenr ||
-   strncmp((char *)(super-magic), BTRFS_MAGIC,
-   sizeof(super-magic))) {
+   super-magic != cpu_to_le64(BTRFS_MAGIC)) {
brelse(bh);
continue;
}
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 5670765..72b1cf1 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -855,8 +855,7 @@ int btrfs_scan_one_device(const char *path, fmode_t flags, 
void *holder,
disk_super = p + (bytenr  ~PAGE_CACHE_MASK);
 
if (btrfs_super_bytenr(disk_super) != bytenr ||
-   strncmp((char *)(disk_super-magic), BTRFS_MAGIC,
-   sizeof(disk_super-magic)))
+   disk_super-magic != cpu_to_le64(BTRFS_MAGIC))
goto error_unmap;
 
devid = btrfs_stack_device_id(disk_super-dev_item);
-- 
1.7.11.7

--
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: Snapshot Cleaner not Working with inode_cache

2013-02-19 Thread Liu Bo 
On Tue, Feb 19, 2013 at 02:22:27PM -0600, Mitch Harder wrote:
 I've encountered an issue where the space from previously deleted
 snapshots is not being freed up by the cleaner thread.
 
 I'm only encountering this issue when I mount with the inode_cache option.
 
 I've reproduced this on a 3.7.9 kernel merged with the latest
 for-linus branch.  No additional patches are involved.  My testing
 partition is 16 GB.
 
 There is nothing in dmesg indicating any issues.
 
 A simple manual test can reproduce the issue on my box
 
 (1)  Format a fresh, scratch btrfs partition (it would probably work
 with an existing test partition, but I always like to test things that
 seem broken on a scratch partition).
 (2)  Mount partition (my options are -o
 compress-force=lzo,inode_cache).  My mount command was:
 mount -o compress-force=lzo,inode_cache /dev/sda7 /mnt/benchmark/
 (3)  Make a subvolume:  cd /mnt/device; btrfs su create test1
 (4)  Untar kernel sources to the subvolume:  cd test1; tar -xpf
 path/to/kernel/source/tarball
 I believe anything you use to populate the subvolume is sufficient.
 (5)  Make a note of the disk usage:  df -T /mnt/device
 (6)  Remove the subvolume:  cd ..; btrfs su delete test1
 (7)  Wait 2 minutes, and notice that the space has not been freed up.
 I've waited much longer, but I forget the exact timeout on the cleaner
 thread.
 df -T /mnt/device
 
 If I unmount and remount the partition with the same mount options,
 the cleaner will begin to correctly free the space.

Hi Mitch,

Good summary.

 
 I've never used the inode_cache option before, so I'll try a few other
 kernels to see if this is a regression.

I think I know why inode_cache keeps us from freeing space, inode_cache adds
a cache_inode in each btrfs root, and this cache_inode will be iput at the very
last of stage during umount, ie. after we do cleanup work on old
snapshot/subvols, where we free the space.

A remount will force btrfs to do cleanup work on old snapshots during mount.

This may explain the situation.

thanks,
liubo

 --
 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: Fixing mount points

2013-02-19 Thread Bob McGowan 

On 02/18/2013 09:08 AM, Chris Murphy wrote:
 On Feb 18, 2013, at 12:45 AM, Bob McGowan ramjr0...@gmail.com wrote:

 Even though things look OK from the command line, logging in through the
 window system fails (actually, just hangs).

 I assume this means I should be doing something to clean up the
 subvolume?  Or maybe there's something in the Window system
 configuration to change?

 I'm running Linux Mint 14 KDE.  My fstab for the parts in question looks
 like:

 # / was on /dev/sde2 during installation
 UUID=1a...9 / btrfs   defaults,subvol=@ 0   1
 # /home was on /dev/sde2 during installation
 UUID=1a...9 /home btrfs   defaults,subvol=@home 0   2

 What I want is something like:
 # / was on /dev/sde2 during installation
 UUID=1a...9 / btrfs   defaults  0   1
 # /home is on /dev/sda1
 UUID=7f...3 /home btrfs   defaults  0   2
 The 2nd fstab implies a completely different disk, the first partition is 
 btrfs, mounted as /home. So long as the contents are user folders, i.e. the 
 same thing found in sde2 subvol @home, then it's functionally the same as 
 what you had before.

 Also, btrfs doesn't need fs_passno set.


 Chris Murphy
Hi, Chris,

Thanks for the information.  As for fs_passno, what you're seeing is
what was put there by the install process.  I'm assuming, if it's not
needed, that the proper value would be zero?

You have confirmed what I thought was correct.  But trying it the first
time failed.  My login acted as though the user was valid but login
didn't complete, returning to the login screen.

Since I was just able to reconfigure fstab, and it worked, I'd say I
probably fat fingered something and just didn't notice.

In any case, many thanks, again. ;)

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