On Thu, Oct 3, 2019 at 6:18 AM Robert Krig
wrote:
>
> By the way, how serious is the error I've encountered?
> I've run a second scrub in the meantime, it aborted when it came close
> to the end, just like the first time.
> If the files that are corrupt have been deleted is this error going to
> g
Hi,
I seem to have another case where scrub gets confused when it is
cancelled and restarted many times (or, maybe, it is my error or
something). I will look into it further but, instead of just hacking
away at my script to work out what is going on, I thought I might try to
create a regression te
The parameter is now always set to NULL and could be dropped. The last
user was get_default_root but that got reworked in 05dbe6837b60 ("Btrfs:
unify subvol= and subvolid= mounting") and the parameter became unused.
Signed-off-by: David Sterba
---
fs/btrfs/ctree.h| 5 ++---
fs/btrfs
During a cyclic writeback, extent_write_cache_pages() uses done_index
to update the writeback_index after the current run is over. However,
instead of current index + 1, it gets to to the current index itself.
Unfortunately, this, combined with returning on EOF instead of looping
back, can lead t
Its very helpful if we had logged the device scanner process name
to debug the race condition between the systemd-udevd scan and the
user initiated device forget command.
This patch adds scanned-by process name to the scan message.
Signed-off-by: Anand Jain
---
v2: add pid as well
fs/btrfs/vol
On 3/10/19 9:24 PM, David Sterba wrote:
On Wed, Oct 02, 2019 at 06:30:48PM +0800, Anand Jain wrote:
Its very helpful if we had logged the device scanner process name
to debug the race condition between the systemd-udevd scan and the
user initiated device forget command.
This patch adds scann
On Wed, Oct 02, 2019 at 06:30:48PM +0800, Anand Jain wrote:
> Its very helpful if we had logged the device scanner process name
> to debug the race condition between the systemd-udevd scan and the
> user initiated device forget command.
>
> This patch adds scanned-by process name to the scan messa
On Thu, Oct 03, 2019 at 02:55:59PM +0200, David Sterba wrote:
> On Thu, Sep 26, 2019 at 01:39:58PM +0300, Nikolay Borisov wrote:
> > >> - if (backref_in_log(log_root, &search_key, dirid, name, name_len))
> > >> + ret = backref_in_log(log_root, &search_key, dirid, name,
> > >> name_len)
On Thu, Sep 26, 2019 at 01:39:58PM +0300, Nikolay Borisov wrote:
> >> - if (backref_in_log(log_root, &search_key, dirid, name, name_len))
> >> + ret = backref_in_log(log_root, &search_key, dirid, name, name_len);
> >> + if (ret == 1)
> >> return true;
> >
> > This
By the way, how serious is the error I've encountered?
I've run a second scrub in the meantime, it aborted when it came close
to the end, just like the first time.
If the files that are corrupt have been deleted is this error going to
go away?
On Mi, 2019-10-02 at 12:17 +0200, Robert Krig wrote
On Thu, Oct 3, 2019 at 8:55 AM Qu Wenruo wrote:
>
> Add a regression test to check if btrfs can handle high devid.
>
> The test will add and remove devices to a btrfs fs, so that the devid
> will increase to uncommon but still valid values.
>
> The regression is introduced by kernel commit ab4ba2e
On Thu, Oct 3, 2019 at 11:59 AM Filipe Manana wrote:
>
> On Wed, Oct 2, 2019 at 7:44 PM Josef Bacik wrote:
> >
> > I discovered a problem in btrfs where we'd end up pointing at a block we
> > hadn't written out yet. This is triggered by a race when two different
> > files on two different subvol
On Wed, Oct 2, 2019 at 7:44 PM Josef Bacik wrote:
>
> I discovered a problem in btrfs where we'd end up pointing at a block we
> hadn't written out yet. This is triggered by a race when two different
> files on two different subvolumes fsync. This test exercises this path
> with dm-log-writes, a
Add a regression test to check if btrfs can handle high devid.
The test will add and remove devices to a btrfs fs, so that the devid
will increase to uncommon but still valid values.
The regression is introduced by kernel commit ab4ba2e13346 ("btrfs:
tree-checker: Verify dev item").
The fix is ti
14 matches
Mail list logo
