[PATCH v2 1/2] btrfs: change num_items type from u64 to unsigned int

The value of num_items that start_transaction() ultimately always takes is a small one, so a 64 bit integer is overkill. Also change num_items for btrfs_start_transaction() and btrfs_start_transaction_lflush() as well. Signed-off-by: Alexandru Moise <00moses.alexande...@gmail.com> --- v2:

Re: [PATCH v2 1/9] vfs: add copy_file_range syscall and vfs helper

On 09/22/2015 07:44 AM, David Sterba wrote: > On Fri, Sep 11, 2015 at 04:30:14PM -0400, Anna Schumaker wrote: >> From: Zach Brown >> +/* >> + * copy_file_range() differs from regular file read and write in that it >> + * specifically allows return partial success. When it does

Re: RAID1 storage server won't boot with one disk missing

On 2015-09-22 14:35, Chris Murphy wrote: On Tue, Sep 22, 2015 at 7:21 AM, Austin S Hemmelgarn wrote: It's not a bad idea, except that it changes established usage, and there are probably some people out there who depend on the current behavior. If we do go that way,

Re: btrfs receive bigger than original snapshot?

On Tue, Sep 22, 2015 at 09:52:19PM +0200, carlo von lynX wrote: > Hello, it's me again. This time I searched the web to make sure > I'm not making another beginner's mistake. I'm still not on the > list, so please keep me in cc: on replies. > > I have optimized a btrfs subvolume with a script*

Re: [PATCH 1/3] btrfs-progs: tests: Move extract_image out of check_all_images for common use

On Fri, Sep 04, 2015 at 09:23:49PM +0800, Zhao Lei wrote: > Move code for extract image file to a function from check_all_images() > for common use, so caller can use this function to extrace single > image file. Moving the code to a wrapper is good but return value via a variable is not. The

Re: [PATCH] btrfs: Fix no space bug caused by removing bg

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/22/15 9:36 AM, Holger Hoffstätte wrote: > On 09/22/15 14:59, Jeff Mahoney wrote: (snip) >> So if they way we want to prevent the loss of raid type info is >> by maintaining the last block group allocated with that raid >> type, fine, but that's a

[PATCH v2 2/2] btrfs: declare rsv_count as unsigned int instead of int

rsv_count ultimately gets passed to start_transaction() which now takes an unsigned int as its num_items parameter. The value of rsv_count should always be positive so declare it as being unsigned. Signed-off-by: Alexandru Moise <00moses.alexande...@gmail.com> --- v2: followed dave's suggestions

[PATCH 0/2] btrfs: Fix returned errno codes

From: Luis de Bethencourt Hi, These two patches fix instances where -1 is used to specify a buffer allocation fail, instead of using -ENOMEM. I could merge the two patches into one if that's more appropriate. Thanks, Luis Luis de Bethencourt (2): btrfs:

Re: [PATCH] btrfs: Fix no space bug caused by removing bg

On 2015-09-22 13:32, Austin S Hemmelgarn wrote: On 2015-09-22 11:39, Hugo Mills wrote: On Tue, Sep 22, 2015 at 10:54:45AM -0400, Austin S Hemmelgarn wrote: On 2015-09-22 10:36, Hugo Mills wrote: On Tue, Sep 22, 2015 at 04:23:33PM +0200, David Sterba wrote: On Tue, Sep 22, 2015 at 01:41:31PM

[PATCH 1/2] btrfs: check-integrity: Fix returned errno codes

check-integrity is using -1 instead of the -ENOMEM defined macro to specify that a buffer allocation failed. Since the error number is propagated, the caller will get a -EPERM which is the wrong error condition. Also, the smatch tool complains with the following warnings:

[PATCH 2/2] btrfs: reada: Fix returned errno code

reada is using -1 instead of the -ENOMEM defined macro to specify that a buffer allocation failed. Since the error number is propagated, the caller will get a -EPERM which is the wrong error condition. Smatch tool warning: reada_add_block() warn: returning -1 instead of -ENOMEM is sloppy

[PATCH v2] btrfs: cleanup btrfs_balance profile validity checks

Improve readability by generalizing the profile validity checks. Signed-off-by: Alexandru Moise <00moses.alexande...@gmail.com> --- v2: Followed Dave's suggestion and renamed function to validate_convert_profile instead of balance_relocate_invalid fs/btrfs/volumes.c | 21 -

Re: [PATCH] btrfs: Fix no space bug caused by removing bg

On 2015-09-22 11:39, Hugo Mills wrote: On Tue, Sep 22, 2015 at 10:54:45AM -0400, Austin S Hemmelgarn wrote: On 2015-09-22 10:36, Hugo Mills wrote: On Tue, Sep 22, 2015 at 04:23:33PM +0200, David Sterba wrote: On Tue, Sep 22, 2015 at 01:41:31PM +, Hugo Mills wrote: On Tue, Sep 22, 2015 at

[PATCH] fstests: Fix golden output for the new btrfs device replace tests

From: Filipe Manana As a workaround for a regression in the uuid filter introduced by a092363bbdfa ("xfs: test changing UUID on V5 superblock"), the btrfs 100 and 101 tests included an extra white space before the uuid in their golden output files. However commit 48613832ad11

[PATCH] fix ifnullfree.cocci warnings

fs/btrfs/qgroup.c:1463:2-7: WARNING: NULL check before freeing functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb is not needed. Maybe consider reorganizing relevant code to avoid passing NULL values. NULL check before some freeing functions is not needed. Based

[josef-btrfs:enospc-rework 1/9] fs/btrfs/qgroup.c:1463:2-7: WARNING: NULL check before freeing functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb is not needed. Maybe consi

tree: https://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git enospc-rework head: ea67b575b6cd2be0775ddd1ff66968d11288f2c6 commit: 1aa3e6f33600e899b38591d9da156dfdb37ea325 [1/9] Major qgroup regression in 4.2? coccinelle warnings: (new ones prefixed by >>) >>

[PATCH 1/4] Btrfs: use btrfs_get_fs_root in resolve_indirect_ref

From: Josef Bacik The backref code will look up the fs_root we're trying to resolve our indirect refs for, unfortunately we use btrfs_read_fs_root_no_name, which returns -ENOENT if the ref is 0. This isn't helpful for the qgroup stuff with snapshot delete as it won't be able to

[PATCH 3/4] btrfs: Add qgroup tracing

This patch adds tracepoints to the qgroup code on both the reporting side (insert_dirty_extents) and the accounting side. Taken together it allows us to see what qgroup operations have happened, and what their result was. Signed-off-by: Mark Fasheh --- fs/btrfs/qgroup.c

RE: [PATCH] btrfs: Fix no space bug caused by removing bg

Hi, Jeff Mahoney > -Original Message- > From: Jeff Mahoney [mailto:je...@suse.com] > Sent: Tuesday, September 22, 2015 9:00 PM > To: Zhao Lei ; linux-btrfs@vger.kernel.org > Subject: Re: [PATCH] btrfs: Fix no space bug caused by removing bg > > -BEGIN PGP

RE: [PATCH] btrfs: Fix no space bug caused by removing bg

Hi, Filipe David Manana > -Original Message- > At the very least this patch should have its title and description changed - > to > reflect that it attempts to solve only (and partially) the problem of losing > raid > profile type. > When I found the bug in testing v4.3-rc1, the only

Re: [PATCH] fstests: btrfs: add test for quota groups and drop snapshot

On Tue, Sep 22, 2015 at 03:16:49PM -0700, Mark Fasheh wrote: > +tmp=/tmp/$$ > +status=1 # failure is the default! > +trap "_cleanup; exit \$status" 0 1 2 3 15 > + > +_cleanup() > +{ > + rm -fr $tmp > +} Missing a "cd /" (see the "new" template). > +# Create an fs tree of a given height

Re: [PATCH 0/4] btrfs: update qgroups in drop snapshot

Hi Mark, Thanks for all your work on this. Comment on test case is inlined below. Mark Fasheh wrote on 2015/09/22 14:12 -0700: On Tue, Sep 22, 2015 at 01:15:44PM -0700, Mark Fasheh wrote: The entire patch series can be tested with the following xfstests.git patch, which will be sent to the

Re: [PATCH v2 10/9] copy_file_range.2: New page documenting copy_file_range()

On 22/09/15 21:10, Anna Schumaker wrote: > On 09/14/2015 02:32 PM, Darrick J. Wong wrote: >> On Sun, Sep 13, 2015 at 09:50:18AM +0200, Michael Kerrisk (man-pages) wrote: >>> Hi Anna, >>> Furthermore, I even wonder if explicitly specifying flags as >>> COPY_FR_COPY | COPY_FR_REFLINK should just

Re: [PATCH v2 10/9] copy_file_range.2: New page documenting copy_file_range()

Hi Michael, On 09/13/2015 03:50 AM, Michael Kerrisk (man-pages) wrote: > Hi Anna, > > On 09/11/2015 10:30 PM, Anna Schumaker wrote: >> copy_file_range() is a new system call for copying ranges of data >> completely in the kernel. This gives filesystems an opportunity to >> implement some kind

[PATCH 2/4] Btrfs: keep dropped roots in cache until transaction commit, V2

From: Josef Bacik When dropping a snapshot we need to account for the qgroup changes. If we drop the snapshot in all one go then the backref code will fail to find blocks from the snapshot we dropped since it won't be able to find the root in the fs root cache. This can lead to

[PATCH 0/4] btrfs: update qgroups in drop snapshot

Hi, The following 4 patches fix a regression introduced in Linux 4.2 where btrfs_drop_snapshot() wasn't updating qgroups, resulting in them going bad. The original e-mail pointing this out is below: http://www.spinics.net/lists/linux-btrfs/msg46093.html The first two patches are from Josef

[PATCH 4/4] btrfs: qgroup: account shared subtree during snapshot delete

Commit 0ed4792 ('btrfs: qgroup: Switch to new extent-oriented qgroup mechanism.') removed our qgroup accounting during btrfs_drop_snapshot(). Predictably, this results in qgroup numbers going bad shortly after a snapshot is removed. Fix this by adding a dirty extent record when we encounter

Re: [PATCH 0/4] btrfs: update qgroups in drop snapshot

On Tue, Sep 22, 2015 at 01:15:44PM -0700, Mark Fasheh wrote: > The entire patch series can be tested with the following xfstests.git > patch, which will be sent to the appropriate list shortly) > > https://github.com/markfasheh/xfstests/commit/b09ca51c012824e44546b13862ab1f93a6f2f675 That

Re: [PATCH 0/4] btrfs: update qgroups in drop snapshot

Hi Mark, I'd like to test the patchset, but it seems to be a little out of date, and failed to apply to integration-4.3. Would you please rebase it to integration-4.3? Thanks, Qu Mark Fasheh wrote on 2015/09/22 13:15 -0700: Hi, The following 4 patches fix a regression introduced in Linux

Re: [PATCH] btrfs: Fix no space bug caused by removing bg

Austin S Hemmelgarn posted on Tue, 22 Sep 2015 13:32:58 -0400 as excerpted: >> Of course, you shouldn't be nesting subvolumes anyway. It makes >> it much harder to manage them. > > That depends though, I only ever do single nesting (ie, a subvolume in a > subvolume), and I use it to exclude

Re: problem with long running btrfs mount operation

Hi, >>> On Tue, Sep 22, 2015 at 9:53 AM, Holger Hoffstätte >>> wrote: On 09/22/15 15:38, S. Fricke wrote: > I have a problem with one of my btrfs hdds. If I mount it, it needs more > than > 135 minutes for this operation. After the mounting

Re: kernel BUG at linux-4.2.0/fs/btrfs/extent-tree.c:1833 on rebalance

在 2015年09月22日 15:34, Stéphane Lesimple 写道: Le 2015-09-22 03:37, Qu Wenruo a écrit : Stéphane Lesimple wrote on 2015/09/22 03:30 +0200: Le 2015-09-20 13:14, Stéphane Lesimple a écrit : Le 2015-09-20 12:51, Qu Wenruo a écrit : Would you please use gdb to show the codes of

Re: kernel BUG at linux-4.2.0/fs/btrfs/extent-tree.c:1833 on rebalance

在 2015年09月22日 16:40, Qu Wenruo 写道: 在 2015年09月22日 15:34, Stéphane Lesimple 写道: Le 2015-09-22 03:37, Qu Wenruo a écrit : Stéphane Lesimple wrote on 2015/09/22 03:30 +0200: Le 2015-09-20 13:14, Stéphane Lesimple a écrit : Le 2015-09-20 12:51, Qu Wenruo a écrit : Would you please use gdb to

Re: kernel BUG at linux-4.2.0/fs/btrfs/extent-tree.c:1833 on rebalance

Le 2015-09-22 03:37, Qu Wenruo a écrit : Stéphane Lesimple wrote on 2015/09/22 03:30 +0200: Le 2015-09-20 13:14, Stéphane Lesimple a écrit : Le 2015-09-20 12:51, Qu Wenruo a écrit : Would you please use gdb to show the codes of "btrfs_qgroup_rescan_worker+0x388" ? (Need kernel debuginfo) My

Re: [PATCH] btrfs: memset cur_trans->delayed_refs to zero

On Tue, Sep 22, 2015 at 03:04:54PM +0200, David Sterba wrote: > On Mon, Sep 07, 2015 at 05:24:37PM +0300, Alexandru Moise wrote: > > Use memset() to null out the btrfs_delayed_ref_root of > > btrfs_transaction instead of setting all the members to 0 by hand. > > > > Signed-off-by: Alexandru Moise

Re: BTRFS kernel error on mounted partition. Partition has errors detected but not repaired by btrfs-check.

Output of first btrfs check --repair (also removed all "bad metadata ..." messages). (TL;DR: The repair failed with "Error: could not find btree root extent for root 1406") squidock# ./btrfs check --repair /dev/sdc1 enabling repair mode Checking filesystem on /dev/sdc1 UUID:

Re: [PATCH] btrfs: memset cur_trans->delayed_refs to zero

On Tue, Sep 22, 2015 at 04:19:36PM +0300, Alexandru Moise wrote: > Alright, do you want me to resend it with the different subject tag > or shall I just keep that in mind for future patches? No need to resend. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body

Re: [PATCH 1/2] btrfs: avoid passing int param to start_transaction which takes u64

On Tue, Sep 22, 2015 at 03:09:33PM +0200, David Sterba wrote: > On Sun, Sep 13, 2015 at 06:47:20PM +, Alexandru Moise wrote: > > Signed-off-by: Alexandru Moise <00moses.alexande...@gmail.com> > > --- > > v2: Forgot to add transaction.h when I made the commit, many thanks > > Holger for

Re: [PATCH] btrfs: Fix no space bug caused by removing bg

On Tue, Sep 22, 2015 at 03:36:43PM +0200, Holger Hoffstätte wrote: > On 09/22/15 14:59, Jeff Mahoney wrote: > (snip) > > So if they way we want to prevent the loss of raid type info is by > > maintaining the last block group allocated with that raid type, fine, > > but that's a separate

Re: [PATCH 1/2] btrfs: avoid passing int param to start_transaction which takes u64

On Tue, Sep 22, 2015 at 04:33:07PM +0300, Alexandru Moise wrote: > > I think it's better to do it the other way around, ie. let all the > > equivalents of 'num_items' be an int. We know that this is a small > > number, using u64 for that is an overkill. As the number is always > > positive, please

Re: [PATCH] btrfs: Fix no space bug caused by removing bg

On Tue, Sep 22, 2015 at 08:59:57AM -0400, Jeff Mahoney wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 [snip] > So if they way we want to prevent the loss of raid type info is by > maintaining the last block group allocated with that raid type, fine, > but that's a separate discussion.

problem with long running btrfs mount operation

Hi, I have a problem with one of my btrfs hdds. If I mount it, it needs more than 135 minutes for this operation. After the mounting it works normaly. This is reproducible only with this hdd. Maybe someone has a clue what is going wrong here. Silvio % uname -a Linux develbox 4.1.6-1-ARCH #1

Re: [PATCH] btrfs: Fix no space bug caused by removing bg

On 09/22/15 14:59, Jeff Mahoney wrote: (snip) > So if they way we want to prevent the loss of raid type info is by > maintaining the last block group allocated with that raid type, fine, > but that's a separate discussion. Personally, I think keeping 1GB At this point I'm much more surprised to

Re: problem with long running btrfs mount operation

On 09/22/15 15:38, S. Fricke wrote: > I have a problem with one of my btrfs hdds. If I mount it, it needs more than > 135 minutes for this operation. After the mounting it works normaly. This is > reproducible only with this hdd. > > Maybe someone has a clue what is going wrong here. On remount

RE: [PATCH] btrfs: Fix no space bug caused by removing bg

Hi, Filipe David Manana > -Original Message- > From: linux-btrfs-ow...@vger.kernel.org > [mailto:linux-btrfs-ow...@vger.kernel.org] On Behalf Of Zhao Lei > Sent: Tuesday, September 22, 2015 6:06 PM > To: fdman...@gmail.com > Cc: linux-btrfs@vger.kernel.org > Subject: RE: [PATCH] btrfs:

Re: [PATCH] btrfs: Fix no space bug caused by removing bg

On Tue, Sep 22, 2015 at 11:06 AM, Zhao Lei wrote: > Hi, Filipe David Manana > > Thanks for review this patch. > >> -Original Message- >> From: Filipe David Manana [mailto:fdman...@gmail.com] >> Sent: Monday, September 21, 2015 9:27 PM >> To: Zhao Lei

Re: BTRFS kernel error on mounted partition. Partition has errors detected but not repaired by btrfs-check.

On Tue, Sep 22, 2015 at 08:55:05AM -0300, Sylvain Joyeux wrote: > Hi > > Hopefully, third time's the charm ... this time I'm subscribed. > > (NB: sorry if you got this twice, but it did not appear in the ML > archives so I'm assuming it never reached the ML ...) > > I am in the situation where

Re: RAID1 storage server won't boot with one disk missing

On 2015-09-21 16:35, Erkki Seppala wrote: Gareth Pye writes: People tend to be looking at BTRFS for a guarantee that data doesn't die when hardware does. Defaults that defeat that shouldn't be used. However, data is no more in danger at startup than it is at the

Re: [PATCH v2 7/9] vfs: Remove copy_file_range mountpoint checks

On Fri, Sep 11, 2015 at 04:30:20PM -0400, Anna Schumaker wrote: > I still want to do an in-kernel copy even if the files are on different > mountpoints, and NFS has a "server to server" copy that expects two > files on different mountpoints. Let's have individual filesystems > implement this

RE: [PATCH] btrfs: Fix no space bug caused by removing bg

Hi, Filipe David Manana Thanks for review this patch. > -Original Message- > From: Filipe David Manana [mailto:fdman...@gmail.com] > Sent: Monday, September 21, 2015 9:27 PM > To: Zhao Lei > Cc: linux-btrfs@vger.kernel.org > Subject: Re: [PATCH] btrfs: Fix no

RE: [PATCH] btrfs: Fix no space bug caused by removing bg

Hi, Filipe David Manana > -Original Message- > From: linux-btrfs-ow...@vger.kernel.org > [mailto:linux-btrfs-ow...@vger.kernel.org] On Behalf Of Filipe David Manana > Sent: Tuesday, September 22, 2015 6:22 PM > To: Zhao Lei > Cc: linux-btrfs@vger.kernel.org >

Re: [PATCH v2 1/9] vfs: add copy_file_range syscall and vfs helper

On Fri, Sep 11, 2015 at 04:30:14PM -0400, Anna Schumaker wrote: > From: Zach Brown > +/* > + * copy_file_range() differs from regular file read and write in that it > + * specifically allows return partial success. When it does so is up to > + * the copy_file_range method. > +

Re: [PATCH v2 4/9] vfs: Copy should check len after file open mode

On Fri, Sep 11, 2015 at 04:30:17PM -0400, Anna Schumaker wrote: > I don't think it makes sense to report that a copy succeeded if the > files aren't open properly. > > Signed-off-by: Anna Schumaker Reviewed-by: David Sterba -- To unsubscribe from

Re: [PATCH v2 5/9] vfs: Copy shouldn't forbid ranges inside the same file

On Fri, Sep 11, 2015 at 04:30:18PM -0400, Anna Schumaker wrote: > This is perfectly valid for BTRFS and XFS, so let's leave this up to > filesystems to check. > > Signed-off-by: Anna Schumaker For the btrfs part, Reviewed-by: David Sterba -- To

Re: [PATCH v2 9/9] btrfs: btrfs_copy_file_range() only supports reflinks

On Fri, Sep 11, 2015 at 04:30:22PM -0400, Anna Schumaker wrote: > Reject copies that don't have the COPY_FR_REFLINK flag set. > > Signed-off-by: Anna Schumaker Reviewed-by: David Sterba -- To unsubscribe from this list: send the line "unsubscribe

Re: BTRFS kernel error on mounted partition. Partition has errors detected but not repaired by btrfs-check.

Hi Hopefully, third time's the charm ... this time I'm subscribed. (NB: sorry if you got this twice, but it did not appear in the ML archives so I'm assuming it never reached the ML ...) I am in the situation where a partition has errors, detected by btrfs-check but not repaired by it. Mounting

Re: [PATCH RFC 00/14] Yet Another In-band(online) deduplication implement

On Mon, Aug 31, 2015 at 09:13:29AM +0800, Qu Wenruo wrote: > > That's the wrong interface to use for such actions. > > > But IMHO, deduplication is much like compression, we only need to > execution extra hook to handle data at run_delalloc_range(). It is, but the filesystem-wide compression

Re: problem with long running btrfs mount operation

On Tue, Sep 22, 2015 at 04:57:35PM +0200, Holger Hoffstätte wrote: > On 09/22/15 16:43, S. Fricke wrote: > >> On Tue, Sep 22, 2015 at 9:53 AM, Holger Hoffstätte > >> wrote: > >>> On 09/22/15 15:38, S. Fricke wrote: > I have a problem with one of my btrfs

Re: [PATCH] btrfs: Fix no space bug caused by removing bg

On Tue, Sep 22, 2015 at 01:41:31PM +, Hugo Mills wrote: > On Tue, Sep 22, 2015 at 03:36:43PM +0200, Holger Hoffstätte wrote: > > On 09/22/15 14:59, Jeff Mahoney wrote: > > (snip) > > > So if they way we want to prevent the loss of raid type info is by > > > maintaining the last block group

Re: [PATCH 2/3] btrfs: use btrfs_raid_array for btrfs_get_num_tolerated_disk_barrier_failures()

On Tue, Sep 15, 2015 at 09:08:07PM +0800, Zhao Lei wrote: > btrfs_raid_array[] is used to define all raid attributes, use it > to get tolerated_failures in btrfs_get_num_tolerated_disk_barrier_failures(), > instead of complex condition in function. > > It can make code simple and auto-support

Re: [PATCH] btrfs: Fix no space bug caused by removing bg

On 2015-09-22 10:36, Hugo Mills wrote: On Tue, Sep 22, 2015 at 04:23:33PM +0200, David Sterba wrote: On Tue, Sep 22, 2015 at 01:41:31PM +, Hugo Mills wrote: On Tue, Sep 22, 2015 at 03:36:43PM +0200, Holger Hoffstätte wrote: On 09/22/15 14:59, Jeff Mahoney wrote: (snip) So if they way we

Re: [PATCH 1/3] btrfs: Move btrfs_raid_array to public

On Tue, Sep 15, 2015 at 09:08:06PM +0800, Zhao Lei wrote: > This array is used to record attributes of each raid type, > make it public, and many functions will benifit with this array. > > For example, num_tolerated_disk_barrier_failures(), we can > avoid complex conditions in this function, and

Re: problem with long running btrfs mount operation

On Tue, Sep 22, 2015 at 9:53 AM, Holger Hoffstätte wrote: > On 09/22/15 15:38, S. Fricke wrote: >> I have a problem with one of my btrfs hdds. If I mount it, it needs more than >> 135 minutes for this operation. After the mounting it works normaly. This is >>

Re: [PATCH] btrfs: Fix no space bug caused by removing bg

On Tue, Sep 22, 2015 at 04:23:33PM +0200, David Sterba wrote: > On Tue, Sep 22, 2015 at 01:41:31PM +, Hugo Mills wrote: > > On Tue, Sep 22, 2015 at 03:36:43PM +0200, Holger Hoffstätte wrote: > > > On 09/22/15 14:59, Jeff Mahoney wrote: > > > (snip) > > > > So if they way we want to prevent the

Re: [PATCH v2 0/9] free space B-tree

On Fri, Sep 11, 2015 at 09:21:13AM +0800, Qu Wenruo wrote: > Also, it should provide a quite good base for rework inode cache for > future development. You mean what's now under 'inode_cache' mount option? It builds on the free space cache infrastructure so it would be natural to use it as well.

Re: [PATCH] btrfs: cleanup btrfs_balance profile validity checks

On Sun, Aug 30, 2015 at 09:45:49PM +, Alexandru Moise wrote: > Improve readability by generalizing the profile validity checks, > I had to read through those if statements half a dozen times on my > first try just to get an idea of what's happening there. > > Signed-off-by: Alexandru Moise

Re: [PATCH 1/2] btrfs: avoid passing int param to start_transaction which takes u64

On Sun, Sep 13, 2015 at 06:47:20PM +, Alexandru Moise wrote: > Signed-off-by: Alexandru Moise <00moses.alexande...@gmail.com> > --- > v2: Forgot to add transaction.h when I made the commit, many thanks > Holger for pointing it out. > > fs/btrfs/transaction.c | 2 +- > fs/btrfs/transaction.h

Re: [PATCH] btrfs: Fix no space bug caused by removing bg

On Tue, Sep 22, 2015 at 12:24 PM, Zhao Lei wrote: > Hi, Filipe David Manana > >> -Original Message- >> From: linux-btrfs-ow...@vger.kernel.org >> [mailto:linux-btrfs-ow...@vger.kernel.org] On Behalf Of Filipe David Manana >> Sent: Tuesday, September 22, 2015 6:22

Re: [PATCH] btrfs: Fix no space bug caused by removing bg

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/21/15 8:59 AM, Zhao Lei wrote: > btrfs in v4.3-rc1 failed many xfstests items with '-o > nospace_cache' mount option. > > Failed cases are: > btrfs/008,016,019,020,026,027,028,029,031,041,046,048,050,051,053,054, > > 077,083,084,087,092,094 >

Re: [PATCH] btrfs: use a single if() statement for one outcome in get_block_rsv()

On Wed, Sep 09, 2015 at 12:18:50AM +, Alexandru Moise wrote: > Rather than have three separate if() statements for the same outcome > we should just OR them together in the same if() statement. > > Signed-off-by: Alexandru Moise <00moses.alexande...@gmail.com> Reviewed-by: David Sterba

Re: BTRFS kernel error on mounted partition. Partition has errors detected but not repaired by btrfs-check.

> Not attached to this email. :) Can you just put the text inline? Damn. Here they are. For the record, I felt dumb since the original files (from a week ago) were using btrfs-progs 3.19 (I thought I was using 4.2). "Luckily" it happened again today on another drive, so I'm sending this instead.

Re: RAID1 storage server won't boot with one disk missing

在 2015年09月22日 19:32, Austin S Hemmelgarn 写道: On 2015-09-21 16:35, Erkki Seppala wrote: Gareth Pye writes: People tend to be looking at BTRFS for a guarantee that data doesn't die when hardware does. Defaults that defeat that shouldn't be used. However, data is no

Re: [PATCH] btrfs: memset cur_trans->delayed_refs to zero

On Mon, Sep 07, 2015 at 05:24:37PM +0300, Alexandru Moise wrote: > Use memset() to null out the btrfs_delayed_ref_root of > btrfs_transaction instead of setting all the members to 0 by hand. > > Signed-off-by: Alexandru Moise <00moses.alexande...@gmail.com> Reviewed-by: David Sterba

Re: RAID1 storage server won't boot with one disk missing

On 2015-09-22 08:51, Qu Wenruo wrote: 在 2015年09月22日 19:32, Austin S Hemmelgarn 写道: On 2015-09-21 16:35, Erkki Seppala wrote: Gareth Pye writes: People tend to be looking at BTRFS for a guarantee that data doesn't die when hardware does. Defaults that defeat that

Re: [PATCH 3/3] btrfs: use btrfs_raid_array in btrfs_reduce_alloc_profile

On Tue, Sep 15, 2015 at 09:08:08PM +0800, Zhao Lei wrote: > btrfs_raid_array[] holds attributes of all raid types. > > Use btrfs_raid_array[].devs_min is best way for request > in btrfs_reduce_alloc_profile(), instead of use complex > condition of each raid types. > > Signed-off-by: Zhao Lei

Re: problem with long running btrfs mount operation

Hi, > On Tue, Sep 22, 2015 at 9:53 AM, Holger Hoffstätte > wrote: > > On 09/22/15 15:38, S. Fricke wrote: > >> I have a problem with one of my btrfs hdds. If I mount it, it needs more > >> than > >> 135 minutes for this operation. After the mounting it works

Re: [PATCH v2] btrfs: qgroup: exit the rescan worker during umount

On Wed, Sep 02, 2015 at 06:05:17PM -0700, Justin Maggard wrote: > v2: Fix stupid error while making formatting changes... I haven't noticed any difference between the patches, what exactly did you change? > I was hitting a consistent NULL pointer dereference during shutdown that > showed the

Re: problem with long running btrfs mount operation

On 09/22/15 16:43, S. Fricke wrote: >> On Tue, Sep 22, 2015 at 9:53 AM, Holger Hoffstätte >> wrote: >>> On 09/22/15 15:38, S. Fricke wrote: I have a problem with one of my btrfs hdds. If I mount it, it needs more than 135 minutes for this

Re: [PATCH] btrfs: Fix no space bug caused by removing bg

On Tue, Sep 22, 2015 at 10:54:45AM -0400, Austin S Hemmelgarn wrote: > On 2015-09-22 10:36, Hugo Mills wrote: > >On Tue, Sep 22, 2015 at 04:23:33PM +0200, David Sterba wrote: > >>On Tue, Sep 22, 2015 at 01:41:31PM +, Hugo Mills wrote: > >>>On Tue, Sep 22, 2015 at 03:36:43PM +0200, Holger