Re: utils version and convert crash

On Wed, Dec 2, 2015 at 2:14 AM, Duncan <1i5t5.dun...@cox.net> wrote: > So if you're running into the same problem gentoo's live-git build did, > it's likely because you're building the devel branch cloned from > kernel.org, which is no longer updated. Woah, kernel.org is making a log that looks

[PATCH] btrfs: drop duplicate prefix from scrub workqueues

The helper btrfs_alloc_workqueue will add the "btrfs-" prefix. Signed-off-by: David Sterba --- fs/btrfs/scrub.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c index 2907a77fb1f6..f8f52a61e329 100644 ---

Re: vfs: move btrfs clone ioctls to common code

On Thu, Nov 26, 2015 at 07:50:54PM +0100, Christoph Hellwig wrote: > This patch set moves the existing btrfs clone ioctls that other file > system have started to implement to common code, and allows the NFS > server to export this functionality to remote systems. > > This work is based

Re: [RFC] Btrfs device and pool management (wip)

On 2015-11-30 13:43, Qu Wenruo wrote: > > > On 11/30/2015 03:59 PM, Anand Jain wrote: >> (fixed alignment) >> >> [...] > > I'm overall OK with your *current* hot-spare implement. > It's quite small and straightforward. > Just hope some more more easy-to-implement features, like hot-remove

Re: utils version and convert crash

Output from scrub: sudo btrfs scrub start -Bd /data scrub device /dev/sdd (id 2) done scrub started at Wed Dec 2 07:04:08 2015 and finished after 08:53:53 total bytes scrubbed: 2.47TiB with 0 errors scrub device /dev/sde (id 3) done scrub started at Wed Dec 2 07:04:08

Re: vfs: move btrfs clone ioctls to common code

Hi Steve, we have two APIs in Linux: - the copy_file_range syscall which just is a "do a copy by any means" - the btrfs clone ioctls which have stricter semantics that very much expect a reflink-like operation I plan to also wire up copy_file_range to try the clone_file_range method first

Re: LWN mention

On Mon, 9 Nov 2015 08:10:13 AM Duncan wrote: > Russell Coker posted on Sun, 08 Nov 2015 17:38:32 +1100 as excerpted: > > https://lwn.net/Articles/663474/ > > http://thread.gmane.org/gmane.comp.file-systems.btrfs/49500 > > > > Above is a BTRFS issue that is mentioned in a LWN comment. Has this

Re: Bug/regression: Read-only mount not read-only

On Tue, Dec 01, 2015 at 02:46:32PM +0800, Qu Wenruo wrote: > > > Chris Mason wrote on 2015/11/30 11:48 -0500: > >On Sat, Nov 28, 2015 at 01:46:34PM +, Hugo Mills wrote: > >>We've just had someone on IRC with a problem mounting their FS. The > >>main problem is that they've got a corrupt

Re: Bug/regression: Read-only mount not read-only

On Mon, Nov 30, 2015 at 05:06:00PM +, Hugo Mills wrote: > On Mon, Nov 30, 2015 at 11:48:01AM -0500, Chris Mason wrote: > > On Sat, Nov 28, 2015 at 01:46:34PM +, Hugo Mills wrote: > > >We've just had someone on IRC with a problem mounting their FS. The > > > main problem is that they've

Re: Bug/regression: Read-only mount not read-only

On 12/1/15 1:00 PM, Chris Mason wrote: > On Mon, Nov 30, 2015 at 05:06:00PM +, Hugo Mills wrote: >> On Mon, Nov 30, 2015 at 11:48:01AM -0500, Chris Mason wrote: >>> On Sat, Nov 28, 2015 at 01:46:34PM +, Hugo Mills wrote: We've just had someone on IRC with a problem mounting their

Re: [RFC] Btrfs device and pool management (wip)

On 11/30/2015 11:09 PM, Chris Murphy wrote: On Mon, Nov 30, 2015 at 1:37 PM, Austin S Hemmelgarn wrote: I've had multiple cases of disks that got one write error then were fine for more than a year before any further issues. My thought is add an option to retry that

[PATCH] btrfs: Fix no_space in write and rm loop

I see no_space in v4.4-rc1 again in xfstests generic/102. It happened randomly in some node only. (one of 4 phy-node, and a kvm with non-virtio block driver) By bisect, we can found the first-bad is: commit bdced438acd8 ("block: setup bi_phys_segments after splitting")' But above patch only

Re: [PATCH 05/10] btrfs: Use xattr handler infrastructure

On Mon, Nov 30, 2015 at 10:43:38PM +0100, Andreas Gruenbacher wrote: > Use the VFS xattr handler infrastructure and get rid of similar code in > the filesystem. > > Signed-off-by: Andreas Gruenbacher > Cc: Chris Mason > Cc: Josef Bacik > Cc:

Re: utils version and convert crash

On 2015-12-01 07:57, Gareth Pye wrote: Poking around I just noticed that btrfs de stats /data points out that 3 of my drives have some read_io_errors. I'm guessing that is a bad thing. I assume this would indicate bad hardware and would be a likely cause of system crashes. In general, given

Re: utils version and convert crash

Gareth Pye posted on Tue, 01 Dec 2015 23:38:52 +1100 as excerpted: > One of the first things I checked was that I was using an up to date > btrfs util and it keeps reporting that I'm using version 4.0 (btrfs > --version). This is after confirming that my git clone is up to date, > the last commit

Re: utils version and convert crash

Poking around I just noticed that btrfs de stats /data points out that 3 of my drives have some read_io_errors. I'm guessing that is a bad thing. I assume this would indicate bad hardware and would be a likely cause of system crashes. :( On Tue, Dec 1, 2015 at 11:38 PM, Gareth Pye

divide error in __btrfs_map_block (div64_u64(stripe_nr, stripe_len))

Hi, With the attached (fuzzed) disk image I get this crash on latest linus/master when mounting: BTRFS: device fsid de80ced1-18ac-490c-9afb-cf0a7d66cc7e devid 1 transid 7 /dev/loop0 BTRFS info (device loop0): disk space caching is enabled divide error: [#1] SMP KASAN CPU: 0 PID: 955

utils version and convert crash

I'm getting some crashes when converting from RAID1 to RAID5, I know that there was some issues recently but was lead to believe that there were fixes that should have been in 4.3. (I'm using the ubuntu kernel ppa teams 4.3 kernel) One of the first things I checked was that I was using an up to

Re: utils version and convert crash

Gareth Pye posted on Tue, 01 Dec 2015 23:57:28 +1100 as excerpted: > Poking around I just noticed that btrfs de stats /data points out that 3 > of my drives have some read_io_errors. I'm guessing that is a bad thing. > I assume this would indicate bad hardware and would be a likely cause of >

Re: [RFC] Btrfs device and pool management (wip)

On 12/1/2015 12:05 PM, Brendan Hide wrote: On 11/30/2015 11:09 PM, Chris Murphy wrote: On Mon, Nov 30, 2015 at 1:37 PM, Austin S Hemmelgarn wrote: I've had multiple cases of disks that got one write error then were fine for more than a year before any further issues.