As of now btrfs filesystem show reads directly from
disks. So sometimes output can be stale, mainly when
user want to verify their last operation like,
labeling or device delete or add... etc. so this
patch will read from the kernel ioctl if it finds
that disk is mounted.
Further, to scan for the
This is a prepatory work for the following btrfs fi show command
fixes. So that we have a function get_df to get the fs sizes
v4:
fixes checkpatch.pl errors as suggested by Wang
v3:
accepts Zach review comments
v2:
combined the other patches as below and rebase
btrfs-progs: get string for the
This patch set is about
use of lblkid for the btrfs disk scan and
using this lblkid scan for the fi show and dev scan cli
This includes the comments from David (to use lblkid)
and Zach to show (btrfs fi show) info from kernel when
disk is mounted and from the disks directly when disk
Now with the below kernel patch, the excl operations like dev
add/replace/resize and balance returns the btrfs error
code defined in btrfs.h, this patch will help btrfs-progs
(and thus user) to know the error string on the terminal
(instead of /var/log/messages as previously kernel did).
This
This fix the regression introduced by 830427d
that it no more creates the FS if disk is small
and if no mixed option is provided.
This patch will bring it to the original design
which will force mixed profile when disk is small
and go ahead to create the FS.
Which also means that before we open
By the current code, if the requested size is very large, and all the extents
in the free space cache are small, we will waste lots of the cpu time to cut
the requested size in half and search the cache again and again until it gets
down to the size the allocator can return. In fact, we can know
On thu, 29 Aug 2013 14:45:10 +0200, David Sterba wrote:
On Thu, Aug 29, 2013 at 01:47:38PM +0800, Miao Xie wrote:
By the current code, if the requested size is very large, and all the extents
in the free space cache are small, we will waste lots of the cpu time to cut
the requested size
as of now, when 'btrfs device add' adds a device it doesn't
check if the given device contains an existing FS. This
patch will change that to check the same. which when true
add will fail, and ask user to use -f option to overwrite.
further, since now we have test_dev_for_mkfs() function
to check
On Fri, Aug 30, 2013 at 10:15:27AM +0800, Wang Shilong wrote:
On 08/22/2013 11:47 PM, Josef Bacik wrote:
please use checkpatch.pl to check coding styles before sending patches:
WARNING: line over 80 characters
#86: FILE: fs/btrfs/send.c:4051:
+if
On Fri, Aug 30, 2013 at 09:44:59AM +0800, Wang Shilong wrote:
On 08/30/2013 03:29 AM, Josef Bacik wrote:
The plan is to have a bunch of unit tests that run when btrfs is loaded when
you
build with the appropriate config option. My ultimate goal is to have a test
for every non-static
Btrfs uses an rwsem to control access to its extent tree. Threads will hold a
read lock on this rwsem while they scan the extent tree, and if need_resched()
they will drop the lock and schedule. The transaction commit needs to take a
write lock for this rwsem for a very short period to switch
On Thu, Aug 29, 2013 at 08:21:51PM +0100, Filipe David Borba Manana wrote:
Count: 5013
Range: 25.000 - 497.000; Mean: 82.767; Median: 64.000; Stddev: 49.972
Percentiles: 90th: 141.000; 95th: 182.000; 99th: 287.000
25.000 - 33.930: 211 ##
33.930 - 45.927: 277
When the binary search returns 0 (exact match), the target key
will necessarily be at slot 0 of all nodes below the current one,
so in this case the binary search is not needed because it will
always return 0, and we waste time doing it, holding node locks
for longer than necessary, etc.
Below
On Fri, Aug 30, 2013 at 09:44:28AM -0500, Eric Sandeen wrote:
On 8/29/13 3:19 PM, Chris Murphy wrote:
On Aug 29, 2013, at 1:53 PM, Hugo Mills h...@carfax.org.uk wrote:
On Thu, Aug 29, 2013 at 01:44:54PM -0600, Chris Murphy wrote:
Certainly, if known for sure it won't be more than 30
On Fri, Aug 30, 2013 at 3:14 PM, David Sterba dste...@suse.cz wrote:
On Thu, Aug 29, 2013 at 08:21:51PM +0100, Filipe David Borba Manana wrote:
Count: 5013
Range: 25.000 - 497.000; Mean: 82.767; Median: 64.000; Stddev: 49.972
Percentiles: 90th: 141.000; 95th: 182.000; 99th: 287.000
25.000
On 8/29/13 3:19 PM, Chris Murphy wrote:
On Aug 29, 2013, at 1:53 PM, Hugo Mills h...@carfax.org.uk wrote:
On Thu, Aug 29, 2013 at 01:44:54PM -0600, Chris Murphy wrote:
Certainly, if known for sure it won't be more than 30 seconds?
Mmm... it'll depend on the setting of the commit
On Fri, Aug 30, 2013 at 3:59 PM, David Sterba dste...@suse.cz wrote:
On Fri, Aug 30, 2013 at 03:47:21PM +0100, Filipe David Manana wrote:
Sure.
They're actually better now :)
Thanks. The numbers changed in both samples, but the relative difference
is still 2x improvement in this particular
On Fri, Aug 30, 2013 at 03:47:21PM +0100, Filipe David Manana wrote:
Sure.
They're actually better now :)
Thanks. The numbers changed in both samples, but the relative difference
is still 2x improvement in this particular test.
david
--
To unsubscribe from this list: send the line unsubscribe
On Wed, Aug 14, 2013 at 12:29:10PM +0800, Wang Shilong wrote:
Signed-off-by: Wang Shilong wangsl.f...@cn.fujitsu.com
Signed-off-by: Qu Wenruo quwen...@cn.fujitsu.com
---
v2-v3: availiable parts is not true anymore,remove it.
v1-v2: remove wrong copyrights.
Thanks for the updates, I've put
On Wed, Aug 14, 2013 at 04:16:37PM -0700, Zach Brown wrote:
I *think* the second one is just a typo. The chunk's num_stripes was
already initialized from the record, but it's le16. So we'll set the
item's size based on the record's native num_stripes.
@@ -1117,7 +1117,7 @@ static int
On Wed, Aug 14, 2013 at 04:16:45PM -0700, Zach Brown wrote:
+ { NULL, 0, NULL, 0}
+ NULL_CMD_STRUCT,
It's always the last item, so I think the comma should go away,
currently it's mixed. I'll fix it during commit, too trivial to bother
you.
david
--
To unsubscribe from this
I went through the actual fixes and they're selfcontained and now in
integration. Actually, the compilation fail in 1/1 might be caused by a
old sparse utility on my box, I'll check again later.
thanks,
david
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a
So forever we have had this thing to limit the amount of delalloc pages we'll
setup to be written out to 128mb. This is because we have to lock all the pages
in this range, so anything above this gets a bit unweildly, and also without a
limit we'll happily allocate gigantic chunks of disk space.
If we failed to actually allocate the correct size of the extent to relocate we
will end up in an infinite loop because we won't return an error, we'll just
move on to the next extent. So fix this up by returning an error, and then fix
all the callers to return an error up the stack rather than
On Fri, Aug 30, 2013 at 06:25:54PM +0200, David Sterba wrote:
On Wed, Aug 14, 2013 at 04:16:45PM -0700, Zach Brown wrote:
+ { NULL, 0, NULL, 0}
+ NULL_CMD_STRUCT,
It's always the last item, so I think the comma should go away,
currently it's mixed. I'll fix it during commit,
Very nice, thanks.
I'm getting this error, for each built object file:
$ make V=1 C=1
[SP] ctree.o
Heh, I goofed when building the echo and actual rules, might as well
update that to $ to have it output .c?
@$(check_echo) [SP] $@
$(Q)$(check) $(AM_CFLAGS)
On Fri, Aug 30, 2013 at 02:03:28PM -0700, Zach Brown wrote:
Heh, I goofed when building the echo and actual rules, might as well
update that to $ to have it output .c?
@$(check_echo) [SP] $@
$(Q)$(check) $(AM_CFLAGS) $(CFLAGS) $
Yeah, looks better with .c
sparse
On Thu, Aug 29, 2013 at 02:09:57PM -0400, Josef Bacik wrote:
+#define ASSERT(expr) \
+ (likely(expr) ? (void)0 : assfail(#expr, __FILE__, __LINE__))
+#else
+#define ASSERT(expr) ((void)0)
+#endif
+
+#define btrfs_assert()
This is unused and without any ifdef-ed alternatives, should go
Alex pointed out the consequences after a transaction is not committed
when a subvolume is deleted, so in case of a crash before an actual
commit happens will let the subvolume reappear.
Original post:
http://www.spinics.net/lists/linux-btrfs/msg22088.html
Josef's objections:
On Mon, Aug 19, 2013 at 11:48:32AM -0400, Josef Bacik wrote:
@@ -344,10 +442,12 @@ int main(int ac, char **av)
ac = ac - optind;
if (ac == 0)
print_usage();
- if (logical == 0 !extent_tree)
+ if (logical == 0 (!extent_tree !inode))
There's a conflict
On Thu, Aug 29, 2013 at 11:11:50AM -0500, Eric Sandeen wrote:
Also, I'm curious - I know the code existed before your patch 2/2,
but I don't understand why it reserves 1MB for the first superblock
when the first superblock is actually at 64k. Any idea?
I'm not sure... According to the
On Fri, Aug 30, 2013 at 04:50:37PM +0800, Anand Jain wrote:
This fix the regression introduced by 830427d
ie. that's
btrfs-progs: avoid write to the disk before sure to create fs
please note that the commit id is not stable and may change during
integration branch updates.
I was not sure if
On Fri, Aug 30, 2013 at 07:09:01PM +0800, Anand Jain wrote:
as of now, when 'btrfs device add' adds a device it doesn't
check if the given device contains an existing FS. This
patch will change that to check the same. which when true
add will fail, and ask user to use -f option to overwrite.
On 08/31/2013 07:22 AM, David Sterba wrote:
On Fri, Aug 30, 2013 at 04:50:37PM +0800, Anand Jain wrote:
This fix the regression introduced by 830427d
ie. that's
btrfs-progs: avoid write to the disk before sure to create fs
please note that the commit id is not stable and may change during
34 matches
Mail list logo
