Re: BTRFS as image store for KVM?

On Mon, 05 Oct 2015 11:43:18 +0300 Erkki Seppala wrote: > Lionel Bouton writes: > > > 1/ AFAIK the kernel md RAID1 code behaves the same (last time I checked > > you need 2 processes to read from 2 devices at once) and I've never seen > >

Re: [PATCH 16/23] Btrfs: device path change must be logged

Hi David, Kindly note. This is accepted and sent out as part of the patch which are dependinding together. Thanks, Anand On 10/01/2015 09:47 PM, Anand Jain wrote: On 10/01/2015 09:40 PM, David Sterba wrote: On Fri, Aug 14, 2015 at 06:33:01PM +0800, Anand Jain wrote: >From the issue

[PATCH] Btrfs: optimize check for stale device

optimize check for stale device to only be checked when there is device added or changed. If there is no update to the device, there is no need to call btrfs_free_stale_device(). Signed-off-by: Anand Jain --- fs/btrfs/volumes.c | 3 ++- 1 file changed, 2 insertions(+), 1

Re: BTRFS as image store for KVM?

Rich Freeman posted on Sun, 04 Oct 2015 08:21:53 -0400 as excerpted: > On Sun, Oct 4, 2015 at 8:03 AM, Lionel Bouton > wrote: >> >> This focus on single reader RAID1 performance surprises me. >> >> 1/ AFAIK the kernel md RAID1 code behaves the same (last time I

Re: BTRFS as image store for KVM?

Lionel Bouton writes: > 1/ AFAIK the kernel md RAID1 code behaves the same (last time I checked > you need 2 processes to read from 2 devices at once) and I've never seen > anyone arguing that the current md code is unstable. This indeed seems to be the case on

[PATCH V2 3/3] Btrfs: device path change must be logged

>From the issue diagnosable point of view, log if the device path is changed. Signed-off-by: Anand Jain --- V2: Accepts David's review comment and adds a new ret value 2 for device_list_add() and based on that the caller function would indicate if the path is

[PATCH 1/3] Btrfs: create a helper function to read the disk super

A part of code from btrfs_scan_one_device() is moved to a new function btrfs_read_disk_super(), so that former function looks cleaner and moves the code to ensure null terminating label to it as well. Further there is opportunity to merge various duplicate code on read disk super. Earlier attempt

[PATCH V2 2/3] btrfs: maintain consistency in logging to help debugging

Optional Label may or may not be set, or it might be set at some time later. However while debugging to search through the kernel logs the scripts would need the logs to be consistent, so logs search key words shouldn't depend on the optional variables, instead fsid is better. Signed-off-by:

[PATCH] Btrfs: add missing brelse when superblock checksum fails

looks like oversight, call brelse() when checksum fails. further down the code in the non error path we do call brelse() and so we don't see brelse() in the goto error.. paths. Signed-off-by: Anand Jain --- fs/btrfs/disk-io.c | 1 + 1 file changed, 1 insertion(+) diff

[PATCH v2 2/2] btrfs: qgroup: Don't copy extent buffer to do qgroup rescan

Ancient qgroup code call memcpy() on a extent buffer and use it for leaf iteration. As extent buffer contains lock, pointers to pages, it's never sane to do such copy. The following bug may be caused by this insane operation: [92098.841309] general protection fault: [#1] SMP [92098.841338]

[PATCH v2 1/2] btrfs: Add support to do stack item key operation

Normal btrfs_item_key_to_cpu() will need extent buffer to do it, and there is not stack version to handle in memory leaf. Add btrfs_stack_item_key_to_cpu() function for such operation, which will provide the basis for later qgroup fix. Signed-off-by: Qu Wenruo --- v2:

Re: [PATCH v2] fstests: generic: Check if a bull fallocate will change extent number

On Fri, Oct 02, 2015 at 04:35:53PM +0800, Qu Wenruo wrote: > Hi Dave, I updated the patch and moved it to btrfs. > > But I still has some question about the fallocate behavior. > > Just as the new btrfs test case, I changed the fallocate range, not > to cover the last part, to make the problem

Re: BTRFS as image store for KVM?

On 2015-10-05 07:16, Lionel Bouton wrote: Hi, Le 04/10/2015 14:03, Lionel Bouton a écrit : [...] This focus on single reader RAID1 performance surprises me. 1/ AFAIK the kernel md RAID1 code behaves the same (last time I checked you need 2 processes to read from 2 devices at once) and I've

Re: Issues with unmountable BTRFS raid1 filesystem

On Mon, Oct 05, 2015 at 08:30:17AM -0400, Austin S Hemmelgarn wrote: > I've been having issues recently with a relatively simple setup > using a two device BTRFS raid1 on top of two two device md RAID0's, > and every time I've rebooted since starting trying to use this > particular filesystem,

Re: Can i have a word with you?

-- 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: BTRFS as image store for KVM?

On Mon, Oct 5, 2015 at 7:16 AM, Lionel Bouton wrote: > According to the bad performance -> unstable logic, md would then be the > less stable RAID1 implementation which doesn't make sense to me. > The argument wasn't that bad performance meant that something was

Btrfs progs release 4.2.2

Hi, here's a bugfix release of btrfs-progs, fixes picked from current devel branch. * fi label: use fallback if the label ioctl is not available * convert: check nodesize constraints against commandline features (-O) * scrub: report status 'running' until all devices are finished * device

Re: BTRFS as image store for KVM?

Hi, Le 04/10/2015 14:03, Lionel Bouton a écrit : > [...] > This focus on single reader RAID1 performance surprises me. > > 1/ AFAIK the kernel md RAID1 code behaves the same (last time I checked > you need 2 processes to read from 2 devices at once) and I've never seen > anyone arguing that the

Issues with unmountable BTRFS raid1 filesystem

I've been having issues recently with a relatively simple setup using a two device BTRFS raid1 on top of two two device md RAID0's, and every time I've rebooted since starting trying to use this particular filesystem, I've found it unable to mount and had to recreate it from scratch. This is

Re: BTRFS as image store for KVM?

On Mon, 5 Oct 2015 13:16:03 +0200 Lionel Bouton wrote: > To better illustrate my point. > > According to Phoronix tests, BTRFS RAID-1 is even faster than md RAID1 > most of the time. > > http://www.phoronix.com/scan.php?page=article=btrfs_raid_mdadm=1 > > The

Re: [PATCH 4/4] btrfs-progs: change -t option for subvolume list to print a simple space-separated table (making it machine-readable)

On 2015-10-04 16:34, Goffredo Baroncelli wrote: > On 2015-10-04 05:37, Duncan wrote: >> Goffredo Baroncelli posted on Sat, 03 Oct 2015 19:41:33 +0200 as >> excerpted: >> >>> On 2015-10-03 12:09, Axel Burri wrote: On 2015-10-03 11:56, Goffredo Baroncelli wrote: > On 2015-10-02

[PATCH] Btrfs: fix qgroup sanity tests

With my changes to allow us to find old roots when resolving indirect refs I introduced a regression to the sanity tests. Since we don't really care to go down into the fs roots we just need to have the old behavior of returning ENOENT for dummy roots for the sanity tests. In the future if we

Re: [PATCH 4/4] btrfs-progs: change -t option for subvolume list to print a simple space-separated table (making it machine-readable)

On 2015-10-05 17:42, Goffredo Baroncelli wrote: > Hi Axel, > > On 2015-10-05 17:04, Axel Burri wrote: > [...] >> I still don't think it is wise to bloat things further just for printing >> nice tables. My impression is that "btrfs subvolume list" is >> human-readable enough without the '-t'

Re: [PATCH 4/4] btrfs-progs: change -t option for subvolume list to print a simple space-separated table (making it machine-readable)

Hi Axel, On 2015-10-05 17:04, Axel Burri wrote: [...] > > A quick look at the code shows me that Goffredo is right here, as > __list_subvol_search() always fetches ALL data from > BTRFS_IOC_TREE_SEARCH, putting it into a rbtree for later processing > (assemble full paths, sorting). > > While

Re: BTRFS as image store for KVM?

On 2015-10-05 10:04, Duncan wrote: On Mon, 5 Oct 2015 13:16:03 +0200 Lionel Bouton wrote: To better illustrate my point. According to Phoronix tests, BTRFS RAID-1 is even faster than md RAID1 most of the time.