of
the methods supported by the layer below it.
this will stack to an arbatrary number of layers, only limited by how
large the value is allowed to be limiting the combinational permutations
of all the layers options.
David Lang
--
To unsubscribe from this list: send the line unsubscribe linux
way to figure this out and assemble a
sane order without doing an exaustive search down to find the number of
options for each layer (and since this can be different for different
blocks, you would have to do this each time you invoked this option)
David Lang
--
To unsubscribe from this list
to have each layer do the retries for the layer
below it, that would avoid this stacking problem, but at the cost of
potentially doing a LOT of retries without the upper level being able to
limit it.
David Lang
One problem here is the assumption that the lower levels don't change, and we
know
to be throttled by some layer that can see the
entire picture (either by cutting off the retries after a number, after
some time, or by spacing out the retries to allow other queries to get in
and let the box do useful work in the meantime)
David Lang
--
To unsubscribe from this list: send the line
work in the meantime)
David Lang
That should not be an issue - we have a fast fail path for IO that should
avoid retrying just for those reasons (i.e., for multi-path or when
recovering a flaky drive).
This is not a scheme for unbounded retries. If you have a 3 disk mirror in
RAID1, you
filesystem _only_ report the unwritten pieces of
sparse files as holes (not any other ranges of nulls)
the question I have is how large does the range of nulls need to be before
it's reported as a hole? disk sectors, filesystem blocks, other?
David Lang
--
To unsubscribe from this list: send
On Tue, May 07, 2013 at 10:44:05AM +0200, Stefan Behrens wrote:
On Mon, 6 May 2013 23:11:20 +0200, David Sterba wrote:
Superblock is always 4k, but metadata blocks may be larger. We have to
use the appropriate block size when doing checksums, otherwise they're
wrong.
Signed-off
On Fri, May 10, 2013 at 04:26:32PM +0200, Stefan Behrens wrote:
On 05/10/2013 13:20, David Sterba wrote:
On Tue, May 07, 2013 at 10:44:05AM +0200, Stefan Behrens wrote:
On Mon, 6 May 2013 23:11:20 +0200, David Sterba wrote:
Superblock is always 4k, but metadata blocks may be larger. We have
.0.1) which is unusual.
I've reworked the lib versions after I got warnings from post-rpm-build
checks. The missing .0 in soname is a bug , thanks for the fix.
david
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More
.)
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
On Tue, May 07, 2013 at 08:17:12AM +0200, Jan Schmidt wrote:
On Mon, May 06, 2013 at 23:20 (+0200), David Sterba wrote:
On Mon, May 06, 2013 at 09:14:17PM +0200, Jan Schmidt wrote:
--- a/include/uapi/linux/btrfs.h
+++ b/include/uapi/linux/btrfs.h
@@ -530,6 +530,7 @@ struct
?
30 seconds is the regular transaction commit interval. Tweaking the
value is easy (via a mount option to make it clearly visible):
http://lxr.free-electrons.com/source/fs/btrfs/disk-io.c#L1691
but has implications about data safety in case of a long delay in
combination with a crash.
david
and
Chris eventually got to revert that one...
That was long time ago (3.5) and enospc has been updated since, so this
needs re-evaluation if it still leads to early enospc.
This patch is not in next queue, i wonder if your concern is the reason
of that.
david
--
To unsubscribe from this list
| 12m47.406s | 0m00.004s
It looks like a copy paste error in the 3rd column. No really, this
is a great improvement!
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
makes us much safer and we no longer abort with Dave's fs_mark tester.
With this patch on top of today's next I still hit the abort and will
file a bug.
david
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More
);
+ }
This gets repeated, please use wrapper for that.
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
Current way of specifying the path to match is not very comfortable, but
the feature itself is very useful. Let's save the short option -m for a
more user friendly syntax and keep a long option --path-regex with the
current syntax.
CC: Peter Stuge pe...@stuge.se
Signed-off-by: David Sterba dste
Extend mkfs options to specify optional or potentially backwards
incompatible features.
Signed-off-by: David Sterba dste...@suse.cz
---
man/mkfs.btrfs.8.in | 9
mkfs.c | 124 +++-
2 files changed, 123 insertions(+), 10 deletions
((__packed__));
With __packed__ (which is preferrably written as __packed) the data is
not aligned to u64 as the comment says. Aligning u64's is a good thing,
so (for example) pad the space after type (I don't think we need more
than u16 here).
david
--
To unsubscribe from this list: send the line
.
What's still missing is get_unaligned_* in the BTRFS_SETGET_STACK_FUNCS
macros.
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
On Tue, May 21, 2013 at 11:28:28AM -0700, Mark Fasheh wrote:
+static noinline int fill_data(struct inode *inode, u64 off, u64 len,
+ char **cur_buffer)
+{
+ struct page *page;
+ void *addr;
+ char *buffer;
+ pgoff_t index;
+ pgoff_t last_index;
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
Hi,
please don't forget to mention what changed in a revised version
On Sat, May 25, 2013 at 03:16:39PM +0100, Filipe David Borba Manana wrote:
@@ -228,6 +227,8 @@ out:
free(chunk_root);
free(dev_root);
free(csum_root);
+ if (fs_info)
+ free(fs_info
On Mon, May 27, 2013 at 01:31:13PM +0100, Filipe David Manana wrote:
Right. Just thought it was better to check if the calloc() for fs_info
succeeded before derreferencing it for free'ing its super_copy member
(the function's code doesn't check if any of the malloc() / calloc()
calls returned
the ioctl user transactions, so a
readdir(mountpoint) with a user transaction running can break it.
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
. How about just list_drain?
The list_ prefix makes it imho more readable, we know that list_* are
macros, but 'while_list_drain' does not fit to the group. I'd go for
list_drain or list_drain_entry
david
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body
of the code you've converted uses this, from that
point it's safe, but if this is about to be a public interface, it
should be (at least) documented.
Macro trickery to postpone list_del after the {...} finishes does not
work if kfree/kmem_cache_free/rcu_string_free/... is used.
david
-userspace/-kernel code so we could
apply the bits on kernel too.
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
On Thu, Jun 06, 2013 at 09:35:07AM +0800, Miao Xie wrote:
Onwed, 5 Jun 2013 15:36:36 +0200, David Sterba wrote:
On Wed, Jun 05, 2013 at 10:34:08AM +0800, Miao Xie wrote:
On tue, 4 Jun 2013 16:26:57 -0700, Zach Brown wrote:
On Tue, Jun 04, 2013 at 07:16:53PM -0400, Chris Mason
has clear semantics, it sets nocow on any
new (empty) file just fine.
If you want to switch files between cow-nocow, set the cow-status in
advance and then do cp.
david
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
of letters too soon and -u is descriptive
enough. -c for csum tree works for me as well.
So I'm adding this into integration.
thanks,
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
desired files with -czlib
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
here, it's a few more lines per root.
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
On Thu, Jun 20, 2013 at 06:08:29PM +0100, Filipe David Manana wrote:
Is there any reason why the btrfs progs (except for btrfs-show-super)
don't validate the super block's checksum?
btrfsck accepts broken filesystems, so open_ctree_broken should possibly
detect but skip the checksum mismatch
operations performed
accross vfsmounts and current implementation respects that.
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
That's a good cleanup, please send the kernel version as well.
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
On Wed, Jun 26, 2013 at 01:27:08PM +0800, Qu Wenruo wrote:
--- a/btrfs-convert.c
+++ b/btrfs-convert.c
@@ -1802,7 +1802,7 @@ static int prepare_system_chunk_sb(struct
btrfs_super_block *super)
btrfs_set_stack_chunk_num_stripes(chunk, 1);
btrfs_set_stack_chunk_sub_stripes(chunk,
(stderr, ERROR: '%s' is not a subvolume\n, path);
223 ret = 13;
224 goto out;
225 }
226
227 cpath = realpath(path, 0);
the segfault occurs as well.
david
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message
bytes.
2 Overflow happens(size exceeds YB)
However we're limited to 16 EiB both theoretically and practically due
to everything being 64bit, we can drop the zetta- and yotta- suffixes
eventually.
thanks,
david
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body
On Wed, Jul 03, 2013 at 06:25:59PM +0100, Filipe David Manana wrote:
Also, replacing the BUG_ON with something else would be nice of course.
If you don't mind, I would prefer to do that as a different patch,
since the BUG_ON() use is what is currently done everywhere in this
function
something? It seems that
Josef's btrfs-next still has this issue (as does Chris's for-linus).
Sound analysis and I agree with the fix. The clean-by-one patch has been
merged into 3.10 so we need a stable fix for that.
thanks,
david
--
To unsubscribe from this list: send the line unsubscribe
btrfs_file_extent_item, type, 8);
+BTRFS_SETGET_STACK_FUNCS(stack_file_extent_bytenr,
+ struct btrfs_file_extent_item, disk_bytenr, 64);
Please use the struct member name in the macro name, ie.
stack_file_extent_disk_bytenr
otherwise ok,
Reviewed-by: David Sterba dste...@suse.cz
On Fri, Jul 05, 2013 at 09:43:34PM +0100, Filipe David Borba Manana wrote:
In btrfs_set_block_flags() we want to check if the slot
in the leaf points to the first item in the leaf - if it
doesn't check if the previous item in the leaf is an extent
item. By removing this extra slot decrement we
terminated.
make: *** [btrfs.o] Error 1
Works great, thanks. I've noticed that DEPFLAGS is now unused and
removed it.
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
On Mon, Jul 08, 2013 at 06:46:07PM +0200, David Sterba wrote:
On Sat, Jul 06, 2013 at 05:22:31PM +0900, Kusanagi Kouichi wrote:
Some files don't compile because of insufficient prerequisite.
$ make btrfs
...
[CC] btrfs.o
btrfs.c:24:21: fatal error: version.h: No such file
of the
allocation request and there's nothing like preallocate 30G for whole
balance and put all data together because the space is available.
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
://patchwork.kernel.org/patch/2697501/
Btrfs: free csums when we're done scrubbing an extent
but I don't see it included in the current for-linus branch. We want
this in the 3.10.x stable series and according to stable tree policy it
has to be merged into Linus' tree first.
david
--
To unsubscribe from
and not upstreamable solution, but without it the core
packaging tool zypper would not work correctly.
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
(same as commit bb0eabc383e9a3fde7cdb02591ca88243f3e31fb)
There, 'char' is unsigned, so once assigned '-1' from getopt, it gets
the value 255. Then, it compared to '-1' gives false.
Signed-off-by: David Sterba dste...@suse.cz
---
btrfs-crc.c | 2 +-
cmds-device.c | 2 +-
2 files changed, 2
be to fix ext2fs/ext2_types.h to not
use its own typedefs.
Originally observed in btrfs-convert, put the include into kerncompat.h
to avoid future problems.
Signed-off-by: Michal Marek mma...@suse.cz
Signed-off-by: David Sterba dste...@suse.cz
---
kerncompat.h | 1 +
1 file changed, 1 insertion(+)
diff
The root_item-otime value must be accessed via the macro otherwise the
value is incorrect on big endian machines.
Signed-off-by: David Sterba dste...@suse.cz
---
btrfs-list.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/btrfs-list.c b/btrfs-list.c
index c3d35de..7f34237
localtime may return NULL (when an error is detected eg. after setting
tzname), followed by a segfault when the values is about to be used.
localtime_r works, does not set tzname and does not return NULL.
Signed-off-by: David Sterba dste...@suse.cz
---
btrfs-list.c | 10 ++
cmds
On Tue, Jul 09, 2013 at 01:24:43PM -0700, Zach Brown wrote:
The original codes don't handle error gracefully and some places
forget to free memory. We can allocate memory before calling pretty_sizes(),
for example, we can use static memory allocation and we don't have to deal
with memory
z...@redhat.com
Signed-off-by: David Sterba dste...@suse.cz
---
I've updated the rest of pretty_size callers in targets that were not built by
default.
btrfs-calc-size.c | 13 +++--
btrfs-fragments.c | 2 +-
cmds-filesystem.c | 27 +--
cmds-scrub.c | 8
On Wed, Jul 10, 2013 at 11:31:17PM +0800, Wang Shilong wrote:
Hello David,
From: Zach Brown z...@redhat.com
duplicate information.
git-send-email tricked me, the line is not present in thre tree
From: Zach Brown z...@redhat.com
We don't need callers to manage string storage
On Tue, Jul 09, 2013 at 07:49:53PM +0100, Filipe David Borba Manana wrote:
The module cmds-restore.c was defining its own next_leaf()
function, which did exactly the same as btrfs_next_leaf()
from ctree.c.
This has been removed by Eric's patch present in the integration
branches:
Btrfs-progs
On Wed, Jul 10, 2013 at 05:16:23PM +0100, Hugo Mills wrote:
Sorry to be a pain in the arse at this late stage of the patch, but
I've only just noticed.
No worries, good to have this one fixed.
david
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body
As implemented now, we use 1024 based units but reporting 1000 based,
let's finally fix that and add optional unit bases later.
Signed-off-by: David Sterba dste...@suse.cz
---
utils.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/utils.c b/utils.c
index bce06f1..2e24cb0
On Wed, Jul 10, 2013 at 10:45:45AM -0700, Mark Fasheh wrote:
Well, what do I get when I pretend I don't care any more? The little voice
in my head says keep plugging away. Here's another attempt at fixing this
problem in a sane manner. Basically, this time we're adding a flag to
s_flags which
compared on current 4k-at-a-time
implementation, but the space savings did not justify the speed drop of
HC mode.
I can't say if the patchset will be ready for 3.12 though.
david
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
The log message level 'critical' is verbose enough, 'emergency' beeps on
all terminals.
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/volumes.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index b2d1eac..1fd7b5d
it up in the perf
top profile.
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
250 which is BTRFS_DEV_REPLACE_KEY, plus the
parent transid error this looks like broken/unfinished device replace.
Have you used the 'btrfs device replace' recently?
david
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
didn't think we needed all this extra stuff to replicate
vfs_gettatr().
I don't remember, probably for code simplicity. The updated version
you've sent looks ok to me.
david
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
, and storage.
Any trouble that you could get in to in 300 seconds some other machine
could trivially get in to in 30 with beefier hardware.
That's a good point and lowers my worries a bit, though it would be
interesting to see in what way a beefy machine blows with 300 seconds
set.
david
I'ts hardcoded to 30 seconds which is fine for most users. Higher values
defer data being synced to permanent storage with obvious consequences
when the system crashes. The upper bound is not forced, but a warning is
printed if it's more than 300 seconds (5 minutes).
Signed-off-by: David Sterba
I'ts hardcoded to 30 seconds which is fine for most users. Higher values
defer data being synced to permanent storage with obvious consequences
when the system crashes. The upper bound is not forced, but a warning is
printed if it's more than 300 seconds (5 minutes).
Signed-off-by: David Sterba
is set to btrfs. Run btrfsck on your device and
attach
the output to the bug as well. Thanks,
IIRC fsck did not report anything, the changes were only in memory
(but we'd like the fsck log anyway). I think we're only left to print
more debugging information and wait when it happens again.
david
. As the cleaning process is restartable I'm
ok with removing the bugon.
Reviewed-by: David Sterba dste...@suse.cz
--
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
the name of the namespace: how about _ ? It's short, will never
clash with any other command.
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
-archive.com/linux-btrfs@vger.kernel.org/msg25677.html
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
On Mon, Jul 15, 2013 at 07:36:50PM +0800, Wang Shilong wrote:
valgrind complains open_file_or_dir() causes a memory leak.That is because
if we open a directoy by opendir(), and then we should call closedir()
to free memory.
I've reviewed this and don't see a better way how to fix the leaks
--- a/utils.c
+++ b/utils.c
@@ -1476,11 +1475,11 @@ u64 parse_size(char *s)
return strtoull(s, NULL, 10) * mult;
}
-int open_file_or_dir(const char *fname)
+int open_file_or_dir(const char *fname, DIR **dirstream)
{
int ret;
struct stat st;
- DIR *dirstream =
On Thu, Jul 18, 2013 at 02:05:31PM -0600, Chris Murphy wrote:
On Jul 18, 2013, at 11:33 AM, David Sterba dste...@suse.cz wrote:
The missing data blocks return IO error and the valid data can be read.
Sounds like if I have a degraded 'single' volume, I can simply cp or
rsync
-visible changes to this command.
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
of the previous changes so I'd like to look
at them in context of all the other df/show patches.
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
the mail, a git-friendly way
of applying patches is the patchwork.kernel.org interface, see
https://btrfs.wiki.kernel.org/index.php/Btrfs_source_repositories#Patches_sent_to_mailinglist
how to use it.
david
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body
On Tue, Jul 23, 2013 at 10:43:22AM +0800, Qu Wenruo wrote:
Update the man page of btrfs command to keep up with new commands.
Thanks. Please check if I haven't missed anything, I've used 'wiggle' to
guess-apply the patch and fixed a few conflicts myself.
david
--
To unsubscribe from this list
--sectorsize min block allocation (not mountable
by current kernel)\n);
What if I'm on a ppc64 box? This message will be confusing. I'd stick
'may' into (...)
I'll fix the text wording when committing the patch, no need to resend.
david
--
To unsubscribe from this list: send the line unsubscribe
Add namespace for features under development and the first user.
David Sterba (2):
btrfs-progs: introduce command namespace for development features
btrfs-progs: move chunk-recover command to devel namespace
btrfs.c | 26 +-
1 file changed, 25 insertions(+), 1
and the only way to get the commands is
btrfs _ --help
The commands appear as if they are in the 1st level, but have to be used
from inside _, eg.
btrfs _ newcommand
Once the interface is stable, the command will be moved to the right
place.
Signed-off-by: David Sterba dste...@suse.cz
Signed-off-by: David Sterba dste...@suse.cz
---
btrfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/btrfs.c b/btrfs.c
index dff0d70..4bbce48 100644
--- a/btrfs.c
+++ b/btrfs.c
@@ -252,6 +252,7 @@ const struct cmd_group devel_features_cmd_group = {
NOTE: you have
fixes into documentation updates next time (unless
you're testing my attention).
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
v2 vs v3, so for ease of maintenance
please either drop the section or change it to gplv2. You're free to
insist on v3, then I'm not going to merge the patches.
thanks,
david
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
.
btrfs dedup files dir/*
Liu Bo's dedup patch is in today's integration snapshot
http://repo.or.cz/w/btrfs-progs-unstable/devel.git/shortlog/refs/heads/integration-20130806-2
you can use it as a base.
thanks,
david
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs
On Tue, Aug 06, 2013 at 07:27:20PM +0100, Filipe David Borba Manana wrote:
This change allows for most mount options to be persisted in
the filesystem, and be applied when the filesystem is mounted.
If the same options are specified at mount time, the persisted
values for those options
have this dir flag stored in the attributes, chattr +c dir/, but this
cannot be tuned further - no way to specify the compression algorithm
(or for example the target ratio as compression hint), or we can't say
never compress files in this dir (even if mounted with compression)
etc.
david
, possibly always in a pullable state. On
top of that a bunch of topic branches with the _ features.
Let me know if I missed to answer something important.
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
On Wed, Aug 07, 2013 at 01:26:58PM +0200, David Sterba wrote:
I have to re-organize integration branch(es) better, so there is eg. a
branch without unstable stuff, possibly always in a pullable state. On
top of that a bunch of topic branches with the _ features.
... but then there's no point
the function is currently unused, I'm hesitating to remove it
as it's part of the reada-API and might be handy for anyone going to use
the API in the future.
I agree. As replied here,
http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg24047.html
please keep the function.
david
@vger.kernel.org/msg24047.html
btrfs_start_transaction_lflush()
Transcaction API, removing the func does not make sense without removing
BTRFS_RESERVE_FLUSH_LIMIT at the same time.
Miao introduced this function in 08e007d2e57744472a9424735a to enhance
flushing logic to avoid deadlocks.
david
violations (line too long).
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
...@gentoo.org
Safe to remove.
Reviewed-by: David Sterba dste...@suse.cz
--
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
,
+ sizeof(struct __prelim_ref),
Would be nice to give it a name that matches the slab cache,
btrfs_prelim_ref.
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
On Thu, Aug 08, 2013 at 09:36:52AM +0200, Jan Schmidt wrote:
Weird patch formatting concerning extent_io.c, I assume there are no changes
in
extent_buffer_under_io and btrfs_release_extent_buffer_page, you just moved
btrfs_clone_extent_buffer, right? Perhaps --patience or --minimal could do
On Tue, Aug 06, 2013 at 11:42:47AM -0700, Mark Fasheh wrote:
The following series of patches implements in btrfs an ioctl to do
out-of-band deduplication of file extents.
Reviewed-by: David Sterba dste...@suse.cz
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs
be it.
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
On Thu, Aug 08, 2013 at 10:45:48PM +0100, Filipe David Borba Manana wrote:
8MiB is way too large and likely set by mistake. This is not
a significant issue as in practice the max amount of data
added to an inline extent is also limited by the page cache
and btree leaf sizes.
Signed-off
On Wed, Aug 07, 2013 at 03:46:20PM +0200, Martin Steigerwald wrote:
Because really, the motivation sounds like it's primarily for significant
on-disk format changes controlled by mount options. I understand that
motivation more than being able to persist something like noatime.
For a
Thanks for updating the license. One comment that's applicable to all
patches:
On Wed, Aug 07, 2013 at 01:54:03PM +0800, Wang Shilong wrote:
+.SH AVAILABILITY
+.B btrfs-debug-tree
+is part of btrfs-progs. Btrfs is currently under heavy development,
+and not suitable for any uses other than
1 - 100 of 7926 matches
Mail list logo
