Re: [CORRUPTION FILESYSTEM] Corrupted and unrecoverable file system during the snapshot receive

(synthetic resend) Hi. Is possible that there are transfers, cancellations and other, at the same time, but not in the same subvolume. My script checks that there are no transfers in progress on the same subvolume. Is possible that the same subvolume is mounted several times (temporary mount

Re: [CORRUPTION FILESYSTEM] Corrupted and unrecoverable file system during the snapshot receive

(synthetic resend) I'll try to compile the kernel and mount with the config and option enabled. I keep in mind the side effects of that option. Thanks for all. P.S. Sorry for my bad English. Chris Murphy ha scritto: > On Wed, Dec 21, 2016 at 2:09 PM, Chris Murphy

strange btrfs deadlock

Hey. Had the following on a Debian sid: Linux heisenberg 4.8.0-2-amd64 #1 SMP Debian 4.8.11-1 (2016-12-02) x86_64 GNU/Linux I was basically copying data between several filesystems all on SATA disks attached via USB. Unfortunately I have only little data... The first part may be totally

Re: [PATCH] Btrfs: adjust outstanding_extents counter properly when dio write is split

On 12/23/16 09:13, Liu Bo wrote: Currently how btrfs dio deals with split dio write is not good enough if dio write is split into several segments due to the lack of contiguous space, a large dio write like 'dd bs=1G count=1' can end up with incorrect outstanding_extents counter and endio would

Re: [PATCH] btrfs-progs: Get the highest inode for lost+found

At 12/23/2016 08:47 AM, Goldwyn Rodrigues wrote: On 12/20/2016 06:57 PM, Qu Wenruo wrote: At 12/20/2016 08:08 PM, Goldwyn Rodrigues wrote: From: Goldwyn Rodrigues root->highest_inode is not accurate at the time of creating a lost+found and it fails because the

[PATCH] Btrfs: adjust outstanding_extents counter properly when dio write is split

Currently how btrfs dio deals with split dio write is not good enough if dio write is split into several segments due to the lack of contiguous space, a large dio write like 'dd bs=1G count=1' can end up with incorrect outstanding_extents counter and endio would complain loudly with an assertion.

Re: [PATCH] btrfs-progs: Get the highest inode for lost+found

On 12/20/2016 06:57 PM, Qu Wenruo wrote: > > > At 12/20/2016 08:08 PM, Goldwyn Rodrigues wrote: >> From: Goldwyn Rodrigues >> >> root->highest_inode is not accurate at the time of creating a lost+found >> and it fails because the highest_inode+1 is already present. This >>

Re: btrfs_log2phys: cannot lookup extent mapping

Hi, If the change of disk format between versions is precisely documented, it is plausible to create a utility to convert the old volume to new ones, trigger the workflow, upgrade the kernel and boots up for mounting the new volume. Currently, the btrfs wiki shows partial content of the on-disk

Re: OOM: Better, but still there on

On Thu, Dec 22, 2016 at 08:17:19PM +0100, Michal Hocko wrote: > TL;DR I still do not see what is going on here and it still smells like > multiple issues. Please apply the patch below on _top_ of what you had. I've run the usual procedure again with the new patch on top and the log is now up at:

[josef-btrfs:inet-rework 1/6] net/ipv4/inet_connection_sock.c:45:38: note: in expansion of macro 'sk_v6_rcv_saddr'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git inet-rework head: 749825bc60f7224225ced1dbed77d3cc2b0bd72f commit: a36b30653769d1e20ff0df41533a2766453ced1a [1/6] inet: collapse ipv4/v6 rcv_saddr_equal functions into one config: cris-etrax-100lx_v2_defconfig

Re: OOM: Better, but still there on

TL;DR I still do not see what is going on here and it still smells like multiple issues. Please apply the patch below on _top_ of what you had. On Thu 22-12-16 11:10:29, Nils Holland wrote: [...] > http://ftp.tisys.org/pub/misc/boerne_2016-12-22.log.xz It took me a while to realize that

[josef-btrfs:inet-rework 6/6] net/ipv4/inet_connection_sock.c:256:32: error: 'const struct inet_connection_sock_af_ops' has no member named 'rcv_saddr_equal'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git inet-rework head: 749825bc60f7224225ced1dbed77d3cc2b0bd72f commit: 749825bc60f7224225ced1dbed77d3cc2b0bd72f [6/6] inet: reset tb->fastreuseport when adding a reuseport sk config: i386-allmodconfig (attached as

[josef-btrfs:inet-rework 1/6] net/ipv4/inet_hashtables.c:461:5: error: conflicting types for '__inet_hash'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git inet-rework head: 749825bc60f7224225ced1dbed77d3cc2b0bd72f commit: a36b30653769d1e20ff0df41533a2766453ced1a [1/6] inet: collapse ipv4/v6 rcv_saddr_equal functions into one config: i386-allmodconfig (attached as

Re: btrfs_log2phys: cannot lookup extent mapping

On 2016-12-22 10:14, Adam Borowski wrote: On Thu, Dec 22, 2016 at 10:11:35AM +, Duncan wrote: Given the maturing-but-not-yet-fully-stable-and-mature state of btrfs today, being no further from a usable current backup than the data you're willing to lose, at least worst-case, remains an even

Re: btrfs_log2phys: cannot lookup extent mapping

On Thu, Dec 22, 2016 at 10:11:35AM +, Duncan wrote: > Given the maturing-but-not-yet-fully-stable-and-mature state of btrfs > today, being no further from a usable current backup than the data you're > willing to lose, at least worst-case, remains an even stronger > recommendation than it

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Thu, 2016-12-22 at 00:45 -0800, Christoph Hellwig wrote: > On Wed, Dec 21, 2016 at 12:03:17PM -0500, Jeff Layton wrote: > > > > Only btrfs, ext4, and xfs implement it for data changes. Because of > > this, these filesystems must log the inode to disk whenever the > > i_version counter changes.

Re: [bug report] btrfs: root->fs_info cleanup, add fs_info convenience variables

On 12/22/16 7:53 AM, Dan Carpenter wrote: > Hello Jeff Mahoney, > > This is a semi-automatic email about new static checker warnings. Hi Dan - Thanks for the report. We've already seen this one and the right fix is to remove the checks in btrfs_get_name since exportfs won't pass negative

Re: [RFC PATCH v1 30/30] fs: convert i_version counter over to an atomic64_t

On Thu, 2016-12-22 at 10:38 +0200, Amir Goldstein wrote: > On Wed, Dec 21, 2016 at 7:03 PM, Jeff Layton wrote: > > > > The spinlock is only used to serialize callers that want to increment > > the counter. We can achieve the same thing with an atomic64_t and > > get the

[bug report] btrfs: root->fs_info cleanup, add fs_info convenience variables

Hello Jeff Mahoney, This is a semi-automatic email about new static checker warnings. The patch 0b246afa62b0: "btrfs: root->fs_info cleanup, add fs_info convenience variables" from Jun 22, 2016, leads to the following Smatch complaint: fs/btrfs/export.c:238 btrfs_get_name() warn:

Re: [bug or by design ?] btrfs defrag compression does not persist

On 2016-12-21 21:28, Anand Jain wrote: A quick design specific question. The following command converts file-data-extents to the specified encoder (lzo). $ btrfs filesystem defrag -v -r -f -clzo dir/ However the lzo property does not persist through the file modify. As the above operation

Re: OOM: Better, but still there on

Nils Holland wrote: > Well, the issue is that I could only do everything via ssh today and > don't have any physical access to the machines. In fact, both seem to > have suffered a genuine kernel panic, which is also visible in the > last few lines of the log I provided today. So, basically, both

Re: OOM: Better, but still there on

On Thu, Dec 22, 2016 at 11:27:25AM +0100, Michal Hocko wrote: > On Thu 22-12-16 11:10:29, Nils Holland wrote: > > > However, the log comes from machine #2 again today, as I'm > > unfortunately forced to try this via VPN from work to home today, so I > > have exactly one attempt per machine before

Re: [bug or by design ?] btrfs defrag compression does not persist

Anand Jain posted on Thu, 22 Dec 2016 10:28:28 +0800 as excerpted: > A quick design specific question. > > The following command converts file-data-extents to the specified > encoder (lzo). > >$ btrfs filesystem defrag -v -r -f -clzo dir/ > > However the lzo property does not persist

Re: OOM: Better, but still there on

On Thu 22-12-16 11:10:29, Nils Holland wrote: > On Wed, Dec 21, 2016 at 08:36:59AM +0100, Michal Hocko wrote: > > TL;DR > > there is another version of the debugging patch. Just revert the > > previous one and apply this one instead. It's still not clear what > > is going on but I suspect either

Re: btrfs_log2phys: cannot lookup extent mapping

David Hanke posted on Wed, 21 Dec 2016 08:50:02 -0600 as excerpted: > Thank you for your reply. If I've emailed the wrong list, please let me > know. Well, it's the right list... for /current/ btrfs. For 3.0, as I said your distro lists may be more appropriate. But from the below you do seem

Re: OOM: Better, but still there on

On Wed, Dec 21, 2016 at 08:36:59AM +0100, Michal Hocko wrote: > TL;DR > there is another version of the debugging patch. Just revert the > previous one and apply this one instead. It's still not clear what > is going on but I suspect either some misaccounting or unexpeted > pages on the LRU lists.

Re: [PATCH 0/9 v2] scope GFP_NOFS api

Are there any objections to the approach and can we have this merged to the mm tree? Dave has expressed the patch2 should be dropped for now. I will do that in a next submission but I do not want to resubmit until there is a consensus on this. What do other than xfs/ext4 developers think about

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Wed, Dec 21, 2016 at 12:03:17PM -0500, Jeff Layton wrote: > Only btrfs, ext4, and xfs implement it for data changes. Because of > this, these filesystems must log the inode to disk whenever the > i_version counter changes. That has a non-zero performance impact, > especially on write-heavy

Re: [RFC PATCH v1 30/30] fs: convert i_version counter over to an atomic64_t

On Wed, Dec 21, 2016 at 7:03 PM, Jeff Layton wrote: > The spinlock is only used to serialize callers that want to increment > the counter. We can achieve the same thing with an atomic64_t and > get the i_lock out of this codepath. > Cool work! See some nits and suggestions