Re: btrfs-image hash collision option, super slow

W dniu 13.11.2017 o 04:42, Chris Murphy pisze: > Strange. I was using 4.3.3 and it had been running for over 9 hours at > the time I finally cancelled it. If you're compiling from source, the usual advice would be to "make clean" and make sure you're using the correct executable. If your fs is

Re: [PATCH 0/4] Lowmem mode btrfs fixes exposed by complex tree

On 2017年11月13日 15:34, Qu Wenruo wrote: > The patchset (along with "backref lost" bug fixes and test cases) can be > fetched from github: > https://github.com/adam900710/btrfs-progs/tree/lowmem_fix > > Despite the backref lost false alerts reported by Chris Murphy, there > are still some other

Re: Need help with incremental backup strategy (snapshots, defragmentingt & performance)

On Wed, Nov 1, 2017 at 1:15 AM, Roman Mamedov wrote: > On Wed, 1 Nov 2017 01:00:08 -0400 > Dave wrote: > >> To reconcile those conflicting goals, the only idea I have come up >> with so far is to use btrfs send-receive to perform incremental >> backups

Re: btrfs check fails with: btrfs_alloc_chunk: BUG_ON `ret` triggered, value -28

On Mon, Nov 13, 2017 at 8:45 PM, Chris Murphy wrote: > On Mon, Nov 13, 2017 at 8:08 PM, Ben Hooper wrote: > >> [28205.454029] Code: 79 ff ff ff 49 8b 7c 24 60 89 da 48 c7 c6 68 c7 be a0 >> 31 c0 e8 12 4e fe ff eb 9b 89 de 48 c7 c7 38 c7 be a0 31 c0

Re: [GIT PULL] Btrfs changes for 4.15

On 2017年11月13日 23:35, David Sterba wrote: > Hi, > > please pull the following btrfs changes. There are some new user features and > the usual load of invisible enhancements or cleanups. The branch merges > cleanly, has been frozen in case rc7 was the last one, so I send out the pull > request

btrfs check fails with: btrfs_alloc_chunk: BUG_ON `ret` triggered, value -28

Received another balance error which made the fileyetem RO. Running btrfs check errors out with: volumes.c:1035: btrfs_alloc_chunk: BUG_ON `ret` triggered, value -28 I am still able to mount the filesystem RW but it takes over 10 minutes to mount. So far I have tried different kernel

[PATCH 1/2] btrfs-progs: lowmem check: Fix false alerts of referencer count mismatch for snapshot

Btrfs lowmem check reports such false alerts: -- ERROR: extent[366498091008, 134217728] referencer count mismatch (root: 827, owner: 73782, offset: 134217728) wanted: 4, have: 26 ERROR: extent[366498091008, 134217728] referencer count mismatch (root: 818, owner: 73782, offset: 134217728)

[PATCH 2/2] btrfs-progs: fsck-tests: Introduce test case with keyed data backref with shared tree blocks

For snapshot shared tree blocks with source subvolume, the keyed backref counter only counts the exclusive owned references. In the following case, 258 is a snapshot of 257, which inherits all the reference to this data extent. -- item 4 key (12582912 EXTENT_ITEM 524288) itemoff 3741

Re: btrfs check fails with: btrfs_alloc_chunk: BUG_ON `ret` triggered, value -28

On 2017年11月14日 11:50, Chris Murphy wrote: > On Mon, Nov 13, 2017 at 8:45 PM, Chris Murphy wrote: >> On Mon, Nov 13, 2017 at 8:08 PM, Ben Hooper wrote: >> >>> [28205.454029] Code: 79 ff ff ff 49 8b 7c 24 60 89 da 48 c7 c6 68 c7 be a0 >>> 31 c0 e8 12

Re: btrfs check fails with: btrfs_alloc_chunk: BUG_ON `ret` triggered, value -28

> On 14 Nov 2017, at 11:45 am, Chris Murphy wrote: > > On Mon, Nov 13, 2017 at 8:08 PM, Ben Hooper wrote: > >> [28205.454029] Code: 79 ff ff ff 49 8b 7c 24 60 89 da 48 c7 c6 68 c7 be a0 >> 31 c0 e8 12 4e fe ff eb 9b 89 de 48 c7 c7 38 c7 be a0 31

Re: Need help with incremental backup strategy (snapshots, defragmentingt & performance)

On 14/11/17 06:39, Dave wrote: My rsync command currently looks like this: rsync -axAHv --inplace --delete-delay --exclude-from="/some/file" "$source_snapshop/" "$backup_location" As I learned from Kai Krakow in this maillist, you should also add --no-whole-file if both sides are local.

Re: Read before you deploy btrfs + zstd

Hello David. David Sterba - 13.11.17, 23:50: > while 4.14 is still fresh, let me address some concerns I've seen on linux > forums already. > > The newly added ZSTD support is a feature that has broader impact than > just the runtime compression. The btrfs-progs understand filesystem with > ZSTD

Re: [PATCH 0/4] Lowmem mode btrfs fixes exposed by complex tree

On 2017年11月13日 15:34, Qu Wenruo wrote: > The patchset (along with "backref lost" bug fixes and test cases) can be > fetched from github: > https://github.com/adam900710/btrfs-progs/tree/lowmem_fix Branch updated with new fixes for "referencer count mismatch". Thanks Chris Murphy for his image.

Re: btrfs check fails with: btrfs_alloc_chunk: BUG_ON `ret` triggered, value -28

On Mon, Nov 13, 2017 at 8:08 PM, Ben Hooper wrote: > [28205.454029] Code: 79 ff ff ff 49 8b 7c 24 60 89 da 48 c7 c6 68 c7 be a0 31 > c0 e8 12 4e fe ff eb 9b 89 de 48 c7 c7 38 c7 be a0 31 c0 e8 53 11 5a e0 <0f> > ff eb 87 66 90 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 >

Re: discard on SSDs quickly causes backup trees to vanish

On 2017年11月13日 20:57, Austin S. Hemmelgarn wrote: > On 2017-11-11 19:28, Qu Wenruo wrote: >> >> >> On 2017年11月12日 04:12, Hans van Kranenburg wrote: >>> Hi, >>> >>> On 11/11/2017 04:48 AM, Qu Wenruo wrote: On 2017年11月11日 11:13, Hans van Kranenburg wrote: > On 11/11/2017 03:30 AM, Qu

Re:

Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of

Re: discard on SSDs quickly causes backup trees to vanish

On 2017-11-11 19:28, Qu Wenruo wrote: On 2017年11月12日 04:12, Hans van Kranenburg wrote: Hi, On 11/11/2017 04:48 AM, Qu Wenruo wrote: On 2017年11月11日 11:13, Hans van Kranenburg wrote: On 11/11/2017 03:30 AM, Qu Wenruo wrote: One more chance to recover is never a bad idea. It is a bad

Re: [PATCH] Btrfs: bail out gracefully rather than BUG_ON

On Mon, Oct 30, 2017 at 11:14:38AM -0600, Liu Bo wrote: > If a file's DIR_ITEM key is invalid (due to memory errors) and gets > written to disk, a future lookup_path can end up with kernel panic due > to BUG_ON(). > > This gets rid of the BUG_ON(), meanwhile output the corrupted key and > return

Re: btrfs-image hash collision option, super slow

On Mon, Nov 13, 2017 at 1:02 AM, Piotr Pawłow wrote: > W dniu 13.11.2017 o 04:42, Chris Murphy pisze: >> Strange. I was using 4.3.3 and it had been running for over 9 hours at >> the time I finally cancelled it. > > If you're compiling from source, the usual advice would be to

Re: btrfs check lowmem vs original

On Sun, Nov 12, 2017 at 9:37 PM, Qu Wenruo wrote: > > The final bug about backref counts mismatch, without the image I'm not > really sure what's going on. > > (But extent tree verification is really buggy though) Ahh I imaged the wrong file system! Sorry about that:

[PATCH] Btrfs: fix list_add corruption and soft lockups in fsync

Xfstests btrfs/146 revealed this corruption, [ 58.138831] Buffer I/O error on dev dm-0, logical block 2621424, async page read [ 58.151233] BTRFS error (device sdf): bdev /dev/mapper/error-test errs: wr 1, rd 0, flush 0, corrupt 0, gen 0 [ 58.152403] list_add corruption. prev->next should

Re: btrfs check lowmem vs original

On Mon, Nov 13, 2017 at 11:40 AM, Chris Murphy wrote: > On Sun, Nov 12, 2017 at 9:37 PM, Qu Wenruo wrote: > >> >> The final bug about backref counts mismatch, without the image I'm not >> really sure what's going on. >> >> (But extent tree

Re: btrfs list corruption and soft lockups while testing writeback error handling

On Thu, May 11, 2017 at 03:56:35PM -0400, Chris Mason wrote: > On 05/11/2017 03:52 PM, Jeff Layton wrote: > > On Thu, 2017-05-11 at 07:13 -0400, Jeff Layton wrote: > > > I finally got my writeback error handling test to work on btrfs (thanks, > > > Chris!), by making the filesystem stripe the data

[no subject]

This is the second time i am sending you this Email. I, Friedrich Mayrhofer Donate $ 1,000,000.00 to You, Email Me personally for more details. Regards. Friedrich Mayrhofer This message was sent using IMP, the Internet

[GIT PULL] Btrfs changes for 4.15

Hi, please pull the following btrfs changes. There are some new user features and the usual load of invisible enhancements or cleanups. The branch merges cleanly, has been frozen in case rc7 was the last one, so I send out the pull request early. Thanks. New features: - extend mount options to

Re: [PATCH 1/4] Btrfs: introduce device flags

On Wed, Nov 08, 2017 at 11:46:13AM -0800, Liu Bo wrote: > On Mon, Nov 06, 2017 at 05:40:25PM +0100, David Sterba wrote: > > > + Faulty, /* device is known to have a fault */ > > > + In_sync,/* device is in_sync with rest of array */ > > Enums usually are all caps, and with some

Re: [PATCH] Btrfs: set plug for fsync

On Thu, Nov 09, 2017 at 05:16:16PM -0700, Liu Bo wrote: > Setting plug can merge adjacent IOs before dispatching IOs to the disk > driver. > > Without plug, it'd not be a problem for single disk usecases, but for > multiple disks using raid profile, a large IO can be split to several > IOs of

Read before you deploy btrfs + zstd

Hi, while 4.14 is still fresh, let me address some concerns I've seen on linux forums already. The newly added ZSTD support is a feature that has broader impact than just the runtime compression. The btrfs-progs understand filesystem with ZSTD since 4.13. The remaining key part is the