Клиентские базы Skype: prodawez390 Email: prodawez...@gmail.com Whatsapp: +79139230330

Клиентские базы Skype: prodawez390 Email: prodawez...@gmail.com Whatsapp: +79139230330 -- 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: [PATCH v2 02/14] btrfs-progs: check: introduce function to find dir_item

At 11/08/2016 01:05 AM, David Sterba wrote: On Thu, Nov 03, 2016 at 09:58:21AM +0800, Qu Wenruo wrote: At 11/02/2016 11:21 PM, David Sterba wrote: On Wed, Sep 21, 2016 at 11:15:52AM +0800, Qu Wenruo wrote: From: Lu Fengqi Introduce a new function

[PATCH] Minor coverity defect fix - CID 1125928 In set_file_xattrs: Dereference of an explicit null value

--- cmds-restore.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/cmds-restore.c b/cmds-restore.c index a8c67a5..6c2ea8a 100644 --- a/cmds-restore.c +++ b/cmds-restore.c @@ -509,6 +509,9 @@ static int set_file_xattrs(struct btrfs_root *root, u64 inode, while (cur <

Re: Announcing btrfs-dedupe

On Tue, Nov 15, 2016 at 07:26:53AM -0500, Austin S. Hemmelgarn wrote: > On 2016-11-14 16:10, Zygo Blaxell wrote: > >Why is deduplicating thousands of blocks of data crazy? I already > >deduplicate four orders of magnitude more than that per week. > You missed the 'tiny' quantifier. I'm talking

Re: [PATCH 0/2] btrfs-progs: check: Handle drop_progress correctly for deleted subvolume

Hi, On Thu, Oct 13, 2016 at 07:09:47PM +0800, ethanwu wrote: > The patchsets fixes 2 problems in checking deleted subvolume. > > First, there are cases missing in checking drop_key, this add up the missing > cases, > so the skipping flow could work correctly. > > Second, the drop key is only

Re: list/count mismatch warning in rcu_do_batch (possibly triggered by a btrfs bug).

On Tue, Nov 15, 2016 at 10:53:15AM +0200, Nikolay Borisov wrote: > Hello Paul, > > I'm currently going through a crashdump which seems to indicate some > memory corruption, possibly triggered by btrfs. I have several > entries such as : > > [1626691.276310] BUG: Bad page state in process

Re: Announcing btrfs-dedupe

On 2016-11-14 16:10, Zygo Blaxell wrote: On Mon, Nov 14, 2016 at 02:56:51PM -0500, Austin S. Hemmelgarn wrote: On 2016-11-14 14:51, Zygo Blaxell wrote: Deduplicating an extent that may might be concurrently modified during the dedup is a reasonable userspace request. In the general case

Re: [PATCH] fstests: Block btrfs from test case generic/372

At 11/15/2016 04:57 PM, Christoph Hellwig wrote: On Tue, Nov 15, 2016 at 04:14:10PM +0800, Qu Wenruo wrote: Since btrfs always return the whole extent even part of it is shared with other files, so the hole/extent counts differs for "file1" in this test case. This would need an extremly

Re: [PATCH] fstests: Block btrfs from test case generic/372

On Tue, Nov 15, 2016 at 04:14:10PM +0800, Qu Wenruo wrote: > Since btrfs always return the whole extent even part of it is shared > with other files, so the hole/extent counts differs for "file1" in this > test case. This would need an extremly detailed comment in the test case on why btrfs is

Re: About difference in extent sharing in btrfs and xfs

On Mon, Nov 14, 2016 at 11:47:15PM -0800, Darrick J. Wong wrote: > XFS doesn't split the extent either, internally. The FIEMAP > implementation cross-references extent data with the refcount records, > using extra struct fiemap_extent to report precisely which blocks are > shared and which

list/count mismatch warning in rcu_do_batch (possibly triggered by a btrfs bug).

Hello Paul, I'm currently going through a crashdump which seems to indicate some memory corruption, possibly triggered by btrfs. I have several entries such as : [1626691.276310] BUG: Bad page state in process fstrim pfn:230ee7 [1626691.276488] page:ea0008c3b9c0 count:0 mapcount:0

Re: [PATCH 2/3] btrfs-progs: send: fix handling of multiple snapshots (-p option)

xfstests btrfs/038 fails when this patch is applied. Sorry for my fault. I posted the patch that corrected this problem. [PATCH] btrfs-progs: send: fix failure of xfstests btrfs/038 Thanks, Tsutomu On 2016/10/19 11:35, Tsutomu Itoh wrote: > We cannot send multiple snapshots at once by -p

[PATCH] btrfs-progs: send: fix failure of xfstests btrfs/038

The following patch was imperfect, so xfstests btrfs/038 was failed. 6d4fb3d btrfs-progs: send: fix handling of multiple snapshots (-p option) [before] | # ./check btrfs/038 | FSTYP -- btrfs | PLATFORM -- Linux/x86_64 luna 4.9.0-rc5 | MKFS_OPTIONS -- /dev/sdb3 | MOUNT_OPTIONS --

[PATCH] fstests: Block btrfs from test case generic/372

Since btrfs always return the whole extent even part of it is shared with other files, so the hole/extent counts differs for "file1" in this test case. For example: /-- File 1 Extent 0-\ / \ |<--Extent A-->| \ /

[PATCH] fstests: Block btrfs from test case generic/372

Since btrfs always return the whole extent even part of it is shared with other files, so the hole/extent counts differs for "file1" in this test case. For example: /-- File 1 Extent 0-\ / \ |<--Extent A-->| \ /