lening aanvragen

-- Goedendag,    Het is ons een genoegen u te schrijven met betrekking tot het verstrekken van leningen per postadvertentie. Simple Federal Credit Union, We opereren onder een korte, duidelijke en begrijpelijke algemene voorwaarden. We verstrekken leningen tegen een lage rente van 3%.

[PATCH 2/2] btrfs: fix vanished compression property after failed set

The compression property resets to NULL, instead of the old value if we fail to set the new compression parameter. btrfs prop get /btrfs compression compression=lzo btrfs prop set /btrfs compression zli ERROR: failed to set compression for /btrfs: Invalid argument btrfs prop get /btrfs compres

[PATCH 1/2] btrfs: fix zstd compression parameter

We let to pass zstd compression parameter even if its not fully written. For example: btrfs prop set /btrfs compression zst btrfs prop get /btrfs compression compression=zst zlib and lzo are fine. Fix it by using the expected number of char in strncmp(). Signed-off-by: Anand Jain ---

Re: Allow sending of rw-subvols if file system is mounted ro

On Tue, Mar 12, 2019 at 9:48 AM Martin Raiber wrote: > > Hi, > > I know there are corner cases that probably make this difficult (such as > remounting the file system rw while a send is in progress), but it would > be nice if one could send all subvolumes as long as a file system is > mounted read

Re: Allow sending of rw-subvols if file system is mounted ro

On Tue, Mar 12, 2019 at 2:04 PM Andrei Borzenkov wrote: > > 12.03.2019 18:48, Martin Raiber пишет: > > Hi, > > > > I know there are corner cases that probably make this difficult (such as > > remounting the file system rw while a send is in progress), but it would > > be nice if one could send all

Re: [PATCH v2] Btrfs: fix file corruption after snapshotting due to mix of buffered/DIO writes

On Wed, Feb 27, 2019 at 06:56:10PM +, Filipe Manana wrote: > > > What do you expect by falling back to writeback_inodes_sb()? > > > It all ends up going through the same btrfs writeback path. > > > And as I left it, if an error happens for one root, it still tries to > > > flush writeback for a

Re: Allow sending of rw-subvols if file system is mounted ro

12.03.2019 18:48, Martin Raiber пишет: > Hi, > > I know there are corner cases that probably make this difficult (such as > remounting the file system rw while a send is in progress), but it would > be nice if one could send all subvolumes as long as a file system is > mounted read-only (pretend e

Re: Spurious "ghost" "parent transid verify failed" messages on 4.14.x, 4.20.14

I've got similar errors when doing a balance and send/receive at the same time, in these cases send/receive would abort because of the errors, but it all worked normally after waiting for the balance to finish, no more errors, though now I try to remember to disable any scheduled send/receive jobs

Re: [PATCH v5 0/9] Misc props.c cleanups

On Tue, Mar 12, 2019 at 07:12:24PM +0800, Anand Jain wrote: > > > On 3/11/19 10:41 PM, David Sterba wrote: > > On Sat, Mar 09, 2019 at 08:04:14AM +0800, Anand Jain wrote: > >> On 3/8/19 11:01 PM, David Sterba wrote: > >>> On Fri, Mar 01, 2019 at 12:34:46PM +0800, Anand Jain wrote: > v5: drop

Allow sending of rw-subvols if file system is mounted ro

Hi, I know there are corner cases that probably make this difficult (such as remounting the file system rw while a send is in progress), but it would be nice if one could send all subvolumes as long as a file system is mounted read-only (pretend every subvol ist read-only if the file system is mou

Re: [PATCH 1/7] btrfs: Preallocate chunks in cow_file_range_async

Looks good, Reviewed-by: Johannes Thumshirn -- Johannes ThumshirnSUSE Labs Filesystems jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG N

Re: [PATCH 2/7] btrfs: Rename async_cow to async_chunk

Looks good, Reviewed-by: Johannes Thumshirn -- Johannes ThumshirnSUSE Labs Filesystems jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG N

Re: [PATCH 7/7] btrfs: Factor out common extent locking code in submit_compressed_extents

Looks good, Reviewed-by: Johannes Thumshirn -- Johannes ThumshirnSUSE Labs Filesystems jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG N

Re: [PATCH 6/7] btrfs: Set iotree only once in submit_compressed_extents

Looks good, Reviewed-by: Johannes Thumshirn -- Johannes ThumshirnSUSE Labs Filesystems jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG N

Re: [PATCH 5/7] btrfs: Replace clear_extent_bit with unlock_extent

Looks good, Reviewed-by: Johannes Thumshirn -- Johannes ThumshirnSUSE Labs Filesystems jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG

[PATCH 2/7] btrfs: Rename async_cow to async_chunk

Now that we have an explicit async_chunk struct rename references to variables of this type to async_chunk. No functional changes. Signed-off-by: Nikolay Borisov --- fs/btrfs/inode.c | 60 1 file changed, 30 insertions(+), 30 deletions(-) diff --

[PATCH 4/7] btrfs: Make compress_file_range take only struct async_chunk

All context this function needs is held within struct async_chunk. Currently we not only pass the struct but also every individual member. This is redundant, simplify it by only passing struct async_chunk and leaving it to compress_file_range to extract the values it requires. No functional changes

[PATCH 1/7] btrfs: Preallocate chunks in cow_file_range_async

This commit changes the implementation of cow_file_range_async in order to get rid of the BUG_ON in the middle of the loop. Additionally it reworks the inner loop in the hopes of making it more understandable. The idea is to make async_cow be a top-level structured, shared amongst all chunks being

[PATCH 6/7] btrfs: Set iotree only once in submit_compressed_extents

The inode never changes so it's sufficient to dereference it and get the iotree only once, before the execution of the main loop. No functional changes, only the size of the function is decreased: add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-44 (-44) Function ol

[PATCH v4 0/7] Compress path cleanups

Here is the v4 of the compress path cleanups, this version incorporates feeback from v3, namely: * Use struct_size when calculating the size of the struct to allocated in cow_file_range_async * Reinstated the comment about ihold in cow_file_range_async * Renamed "struct async_chunk *" variab

[PATCH 3/7] btrfs: Remove fs_info from struct async_chunk

The associated btrfs_work already contains a reference to the fs_info so use that instead of passing it via async_chunk. No functional changes. Signed-off-by: Nikolay Borisov Reviewed-by: Johannes Thumshirn --- fs/btrfs/inode.c | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) d

[PATCH 5/7] btrfs: Replace clear_extent_bit with unlock_extent

Signed-off-by: Nikolay Borisov --- fs/btrfs/inode.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index df008aa195b4..0123f7067c8a 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -1204,8 +1204,7 @@ static int cow_file_range_async

[PATCH 7/7] btrfs: Factor out common extent locking code in submit_compressed_extents

Irrespective of whether the compress code fell back to uncompressed or a compressed extent has to be submitted, the extent range is always locked. So factor out the common lock_extent call at the beginning of the loop. No functional changes just removes one duplicate lock_extent call. Signed-off-b

Re: [PATCH v5] btrfs-progs: dump-tree: add noscan option

On 12.03.19 г. 16:19 ч., Hugo Mills wrote: > On Tue, Mar 12, 2019 at 04:16:29PM +0200, Nikolay Borisov wrote: >> >> >> On 12.03.19 г. 15:22 ч., Anand Jain wrote: >>> From: Anand Jain >>> >>> The cli 'btrfs inspect dump-tree ' will scan for the partner devices >>> if any by default. >>> >>> So a

Re: [PATCH v5] btrfs-progs: dump-tree: add noscan option

On Tue, Mar 12, 2019 at 04:16:29PM +0200, Nikolay Borisov wrote: > > > On 12.03.19 г. 15:22 ч., Anand Jain wrote: > > From: Anand Jain > > > > The cli 'btrfs inspect dump-tree ' will scan for the partner devices > > if any by default. > > > > So as of now you can not inspect each mirrored devi

Re: [PATCH v5] btrfs-progs: dump-tree: add noscan option

On 12.03.19 г. 15:22 ч., Anand Jain wrote: > From: Anand Jain > > The cli 'btrfs inspect dump-tree ' will scan for the partner devices > if any by default. > > So as of now you can not inspect each mirrored device independently. > > This patch adds noscan option, which when used won't scan t

a bug on: v4.20.1 : check/main.c:4728: add_data_backref: BUG_ON `!back` triggered, value 1 items checked)

As suggested on irc channel: http://logs.tvrrug.org.uk/logs/%23btrfs/2019-03-11.html#2019-03-11T23:28:40 I should file a bug on btrfs tools: check/main.c:4728: add_data_backref: BUG_ON `!back` triggered, value 1 items checked) after doing btrfs check on a btrfs file system that shows 355

[PATCH v5] btrfs-progs: dump-tree: add noscan option

From: Anand Jain The cli 'btrfs inspect dump-tree ' will scan for the partner devices if any by default. So as of now you can not inspect each mirrored device independently. This patch adds noscan option, which when used won't scan the system for the partner devices, instead it just uses the de

[PATCH] btrfs: Correctly free extent buffer in case btree_read_extent_buffer_pages fails

If a an eb fails to be read for whatever reason - it's corrupted on disk and parent transid/key validations fail or IO for eb pages fail then this buffer must be removed from the buffer cache. Currently the code calls free_extent_buffer if an error occurs. Unfortunately this doesn't achieve the des

Re: [PATCH v5 0/9] Misc props.c cleanups

On 3/11/19 10:41 PM, David Sterba wrote: On Sat, Mar 09, 2019 at 08:04:14AM +0800, Anand Jain wrote: On 3/8/19 11:01 PM, David Sterba wrote: On Fri, Mar 01, 2019 at 12:34:46PM +0800, Anand Jain wrote: v5: drops patch [PATCH v4 03/10] btrfs: trivial, fix c coding style Chanegs ar

Re: [PATCH v2] btrfs: Check the first key and level for cached extent buffer

On 2019/3/12 下午7:07, Nikolay Borisov wrote: > > > On 12.03.19 г. 11:10 ч., Qu Wenruo wrote: >> [BUG] >> When reading a file from a fuzzed image, kernel can panic like: >> BTRFS warning (device loop0): csum failed root 5 ino 270 off 0 csum >> 0x98f94189 expected csum 0x mirror 1 >>

Re: [PATCH v2] btrfs: Check the first key and level for cached extent buffer

On 12.03.19 г. 11:10 ч., Qu Wenruo wrote: > [BUG] > When reading a file from a fuzzed image, kernel can panic like: > BTRFS warning (device loop0): csum failed root 5 ino 270 off 0 csum > 0x98f94189 expected csum 0x mirror 1 > assertion failed: !memcmp_extent_buffer(b, &disk_key, of

[PATCH v2] btrfs: Check the first key and level for cached extent buffer

[BUG] When reading a file from a fuzzed image, kernel can panic like: BTRFS warning (device loop0): csum failed root 5 ino 270 off 0 csum 0x98f94189 expected csum 0x mirror 1 assertion failed: !memcmp_extent_buffer(b, &disk_key, offsetof(struct btrfs_leaf, items[0].key), sizeof(disk_k

Re: [PATCH] btrfs: Check the first key and level for cached extent buffer

On 2019/3/12 下午4:28, Nikolay Borisov wrote: > > > On 12.03.19 г. 9:45 ч., Qu Wenruo wrote: >> [BUG] >> When reading a file from a fuzzed image, kernel can panic like: >> BTRFS warning (device loop0): csum failed root 5 ino 270 off 0 csum >> 0x98f94189 expected csum 0x mirror 1 >>

Re: [PATCH] btrfs: Check the first key and level for cached extent buffer

On 2019/3/12 下午4:34, Nikolay Borisov wrote: > > > On 12.03.19 г. 10:32 ч., Qu Wenruo wrote: >> >> >> On 2019/3/12 下午4:11, Nikolay Borisov wrote: >>> >>> >>> On 12.03.19 г. 9:57 ч., Nikolay Borisov wrote: On 12.03.19 г. 9:45 ч., Qu Wenruo wrote: > [BUG] > When reading a f

Re: [PATCH] btrfs: Check the first key and level for cached extent buffer

On 12.03.19 г. 10:32 ч., Qu Wenruo wrote: > > > On 2019/3/12 下午4:11, Nikolay Borisov wrote: >> >> >> On 12.03.19 г. 9:57 ч., Nikolay Borisov wrote: >>> >>> >>> On 12.03.19 г. 9:45 ч., Qu Wenruo wrote: [BUG] When reading a file from a fuzzed image, kernel can panic like: BTRFS

Re: [PATCH] btrfs: Check the first key and level for cached extent buffer

On 2019/3/12 下午4:11, Nikolay Borisov wrote: > > > On 12.03.19 г. 9:57 ч., Nikolay Borisov wrote: >> >> >> On 12.03.19 г. 9:45 ч., Qu Wenruo wrote: >>> [BUG] >>> When reading a file from a fuzzed image, kernel can panic like: >>> BTRFS warning (device loop0): csum failed root 5 ino 270 off 0

Re: [PATCH] btrfs: Check the first key and level for cached extent buffer

On 12.03.19 г. 9:45 ч., Qu Wenruo wrote: > [BUG] > When reading a file from a fuzzed image, kernel can panic like: > BTRFS warning (device loop0): csum failed root 5 ino 270 off 0 csum > 0x98f94189 expected csum 0x mirror 1 > assertion failed: !memcmp_extent_buffer(b, &disk_key, off

Re: [PATCH] btrfs: Check the first key and level for cached extent buffer

On 12.03.19 г. 9:57 ч., Nikolay Borisov wrote: > > > On 12.03.19 г. 9:45 ч., Qu Wenruo wrote: >> [BUG] >> When reading a file from a fuzzed image, kernel can panic like: >> BTRFS warning (device loop0): csum failed root 5 ino 270 off 0 csum >> 0x98f94189 expected csum 0x mirror 1 >>

Re: [PATCH] btrfs: Check the first key and level for cached extent buffer

On 2019/3/12 下午3:57, Nikolay Borisov wrote: [snip] >> *eb_ret = tmp; >> return 0; >> } >> diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c >> index 298b34721bc0..e2a0cb362d28 100644 >> --- a/fs/btrfs/disk-io.c >> +++ b/fs/btrfs/disk-io.c

Re: [PATCH] btrfs: Check the first key and level for cached extent buffer

On 12.03.19 г. 9:45 ч., Qu Wenruo wrote: > [BUG] > When reading a file from a fuzzed image, kernel can panic like: > BTRFS warning (device loop0): csum failed root 5 ino 270 off 0 csum > 0x98f94189 expected csum 0x mirror 1 > assertion failed: !memcmp_extent_buffer(b, &disk_key, off

[PATCH] btrfs: Check the first key and level for cached extent buffer

[BUG] When reading a file from a fuzzed image, kernel can panic like: BTRFS warning (device loop0): csum failed root 5 ino 270 off 0 csum 0x98f94189 expected csum 0x mirror 1 assertion failed: !memcmp_extent_buffer(b, &disk_key, offsetof(struct btrfs_leaf, items[0].key), sizeof(disk_k