Not sure how this happened, but filter.btrfs including
itself leads to immense sadness for any file that includes it.
(I got a segfault when I tried to run 307)
Signed-off-by: Eric Sandeen sand...@redhat.com
---
diff --git a/common/filter.btrfs b/common/filter.btrfs
index b1aa733..99d04a6 100644
There was a time when sprinkling #ifdefs around was
bad form. ;) We can clean up the code a bit by moving
the leak-list adds/removes into functions and make things
more readable.
Signed-off-by: Eric Sandeen sand...@redhat.com
---
p.s. maybe _debug_ should be in the function names?
*shrug*
I found this patch had been merged into David's unstable btrfs-progs
git, but not into its master git, so don't know the reason. If it need
me to send v2 based on your comments, please let me know, thanks.
On Sun, Apr 21, 2013 at 5:33 PM, Zhi Yong Wu zwu.ker...@gmail.com wrote:
I found this
On Sat, Apr 20, 2013 at 05:49:25PM +0200, Gabriel de Perthuis wrote:
Hi,
The following series of patches implements in btrfs an ioctl to do
offline deduplication of file extents.
I am a fan of this patch, the API is just right. I just have a few tweaks
to suggest to the argument checking.
2 patches here.
The first renames the single .c files which are built into btrfs-$FOO
commands - previously we built i.e. btrfs-calc-size from calc-size.c
IMHO this helps separate out which files are main command-type
files, and which are not. (Eventually I hope to move things
into subdirs to
Add a default rule for any btrfs-$FOO or btrfs-$FOO.static
target, allowing it to be built from btrfs-$FOO.c along with
all the normal userspace objects.
This gets rid of a lot of the cut and pasted rules for
each individual command, and as an added bonus makes it
easy to build any btrfs-$FOO
Not sure how this happened, but filter.btrfs including
itself leads to immense sadness for any file that includes it.
(I got a segfault when I tried to run 307)
It should be including the common/filter not common/filter.btrfs
Signed-off-by: Eric Sandeen sand...@redhat.com
---
diff --git
Not sure how this happened, but filter.btrfs including
itself leads to immense sadness for any file that includes it.
(I got a segfault when I tried to run 307)
It should be including ./common/filter not ./common/filter.btrfs
Signed-off-by: Eric Sandeen sand...@redhat.com
---
cripes, I'm sorry
On thu, 18 Apr 2013 00:17:11 +0200, David Sterba wrote:
On Thu, Apr 11, 2013 at 06:30:16PM +0800, Miao Xie wrote:
In order to avoid this problem, we introduce a lock named super_lock into
the btrfs_fs_info structure. If we want to update incompat/compat flags
of the super block, we must
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 20/04/13 23:32, Eric Sandeen wrote:
+#define btrfs_leak_list_add(new, head) do {} while (0); +#define
btrfs_leak_list_del(entry)do {} while (0);
Shouldn't the trailing semi-colons be omitted?
Roger
-BEGIN PGP SIGNATURE-
With this integration branch commit in place:
2bd1169 btrfs-progs: root_item generation_v2 is out of sync after btrfsck
I started seeing generation mismatch messages from the kernel
at mount time, after a fresh mkfs(!):
btrfs: mismatching generation and generation_v2 found in root item...
This addresses the same issue as did:
2bd1169 btrfs-progs: root_item generation_v2 is out of sync after btrfsck
but rather than optionally updating generation_v2 based
on the size of the existing item, increase the size of the
item as needed, and unconditionally set generation_v2.
This matches
This addresses the same issue as did:
2bd1169 btrfs-progs: root_item generation_v2 is out of sync after btrfsck
but rather than optionally updating generation_v2 based
on the size of the existing item, increase the size of the
item as needed, and unconditionally set generation_v2.
This matches
There was a time when sprinkling #ifdefs around was
bad form. We can clean up the code a bit by moving
the leak-list adds/removes into functions and make things
more readable.
Signed-off-by: Eric Sandeen sand...@redhat.com
---
V2: remove extra semicolons on no-op #defines,
thanks Roger!
p.s.
14 matches
Mail list logo
