Re: [PATCH] btrfs-progs: fsck-tests: verify 'btrfs check --repair' fixes corrupted nlink field

> > apply anymore, but I'm expecting some more changes to it so please adapt > it to the new file Not sure what went wrong, will test the next patch with git apply and send it. > > I prefer 'inode_number' or simple 'ino' for the variable name. > Okay, will use inode_number. > >+ > >+

Re: [PATCH 0/9] Lowmem mode fsck fixes with fsck-tests framework update

At 02/02/2017 08:25 AM, Qu Wenruo wrote: Thanks for your test. At 02/02/2017 06:03 AM, Christoph Anton Mitterer wrote: On Wed, 2017-02-01 at 09:06 +0800, Qu Wenruo wrote: https://github.com/adam900710/btrfs-progs/tree/lowmem_fixes Which is also rebased to latest v4.9.1. Same game as last

Re: [PATCH 0/9] Lowmem mode fsck fixes with fsck-tests framework update

Thanks for your test. At 02/02/2017 06:03 AM, Christoph Anton Mitterer wrote: On Wed, 2017-02-01 at 09:06 +0800, Qu Wenruo wrote: https://github.com/adam900710/btrfs-progs/tree/lowmem_fixes Which is also rebased to latest v4.9.1. Same game as last time, applied to 4.9, no RW mount between

Re: [PATCH 2/2] btrfs: replace: Use ref counts to avoid destroying target device when canceled

At 02/02/2017 06:37 AM, Filipe Manana wrote: On Tue, Jan 17, 2017 at 1:10 AM, Qu Wenruo wrote: When dev-replace and scrub are run at the same time, dev-replace can be canceled by scrub. It's quite common for btrfs/069. While in that case, target device can be

Re: btrfs receive leaves new subvolume modifiable during operation

Graham Cobb posted on Wed, 01 Feb 2017 22:51:34 + as excerpted: >> [C]ouldn't the entire problem be eliminated by properly >> setting the permissions on a directory/subvol upstream of the received >> snapshot? > > I (honestly) don't know. But even if that does work, it is clearly only > a

[PATCH] Btrfs: fix assertion failure when freeing block groups at close_ctree()

From: Filipe Manana At close_ctree() we free the block groups and then only after we wait for any running worker kthreads to finish and shutdown the workqueues. This behaviour is racy and it triggers an assertion failure when freeing block groups because while we are doing it

Re: btrfs receive leaves new subvolume modifiable during operation

On 01/02/17 22:27, Duncan wrote: > Graham Cobb posted on Wed, 01 Feb 2017 17:43:32 + as excerpted: > >> This first bug is more serious because it appears to allow a >> non-privileged user to disrupt the correct operation of receive, >> creating a form of denial-of-service of a send/receive

Re: raid1: cannot add disk to replace faulty because can only mount fs as read-only.

Adam Borowski posted on Wed, 01 Feb 2017 12:55:30 +0100 as excerpted: > On Wed, Feb 01, 2017 at 05:23:16AM +, Duncan wrote: >> Hans Deragon posted on Tue, 31 Jan 2017 21:51:22 -0500 as excerpted: >> > But the current scenario makes it difficult for me to put redundancy >> > back into service!

Re: [PATCH 2/2] btrfs: replace: Use ref counts to avoid destroying target device when canceled

On Tue, Jan 17, 2017 at 1:10 AM, Qu Wenruo wrote: > When dev-replace and scrub are run at the same time, dev-replace can be > canceled by scrub. It's quite common for btrfs/069. > > While in that case, target device can be destroyed at cancel time, > leading to a

Re: btrfs receive leaves new subvolume modifiable during operation

Graham Cobb posted on Wed, 01 Feb 2017 17:43:32 + as excerpted: > This first bug is more serious because it appears to allow a > non-privileged user to disrupt the correct operation of receive, > creating a form of denial-of-service of a send/receive based backup > process. If I decided that

Re: [PATCH 0/9] Lowmem mode fsck fixes with fsck-tests framework update

On Wed, 2017-02-01 at 09:06 +0800, Qu Wenruo wrote: > https://github.com/adam900710/btrfs-progs/tree/lowmem_fixes > > Which is also rebased to latest v4.9.1. Same game as last time, applied to 4.9, no RW mount between the runs. btrfs-progs v4.9 WITHOUT patch: *** #

Re: btrfs receive leaves new subvolume modifiable during operation

On 01/02/17 12:28, Austin S. Hemmelgarn wrote: > On 2017-02-01 00:09, Duncan wrote: >> Christian Lupien posted on Tue, 31 Jan 2017 18:32:58 -0500 as excerpted: >> >>> I have been testing btrfs send/receive. I like it. >>> >>> During those tests I discovered that it is possible to access and modify

[PATCH v2] Btrfs: do not create explicit holes when replaying log tree if NO_HOLES enabled

From: Filipe Manana We log holes explicitly by using file extent items, however when replaying a log tree, if a logged file extent item corresponds to a hole and the NO_HOLES feature is enabled we do not need to copy the file extent item into the fs/subvolume tree, as the

Re: [PATCH] Btrfs: add another missing end_page_writeback on submit_extent_page failure

On Wed, Feb 01, 2017 at 12:27:24PM +0900, takafumi-sslab wrote: > Thanks for your reply. > > I think you mentioned about the below if-block in __extent_writepage(). > > if (nr == 0) { > /* make sure the mapping tag for page dirty gets cleared */ > set_page_writeback(page); >

[PATCH] Btrfs: do not create explicit holes when replaying log tree if NO_HOLES enabled

From: Filipe Manana We log holes explicitly by using file extent items, however when replaying a log tree, if a logged file extent item corresponds to a hole and the NO_HOLES feature is enabled we do not need to copy the file extent item into the fs/subvolume tree, as the

[PATCH] fstests: btrfs: Use compressible data

/dev/urandom is incompressible and, /dev/zero is highly compressible, so both are less effective in testing the compress code logic in btrfs. This patch introduces a text data generator cat /dev/urandom | od to populate the files where /dev/urandom is currently being used in the btrfs test

Re: btrfs receive leaves new subvolume modifiable during operation

On 2017-02-01 00:09, Duncan wrote: Christian Lupien posted on Tue, 31 Jan 2017 18:32:58 -0500 as excerpted: I have been testing btrfs send/receive. I like it. During those tests I discovered that it is possible to access and modify (add files, delete files ...) of the new receive snapshot

Re: raid1: cannot add disk to replace faulty because can only mount fs as read-only.

On Wed, Feb 01, 2017 at 05:23:16AM +, Duncan wrote: > Hans Deragon posted on Tue, 31 Jan 2017 21:51:22 -0500 as excerpted: > > But the current scenario makes it difficult for me to put redundancy > > back into service! How much time did I waited until I find the mailing > > list, subscribe to