From: Gu JinXiang
btrfs-progs now support FST in read-only mode, so when space_cache=v2
enabled, this test case will fail.
Add message to help user to understand this status.
Signed-off-by: Gu JinXiang
---
tests/btrfs/012 | 6 ++
1 file changed, 6
I don't need to recover in this case. I can just remake the filesystem. I'm
just very concerned that this corruption was able to happen. Here is the entire
history of the filesystem:
2017.10.18 create btrfs from 3 drives aka OfflineJ and rsync
data from old madam raid5
On Wed, Oct 25, 2017 at 03:23:11PM +0200, David Sterba wrote:
> On Sat, Oct 21, 2017 at 06:49:01PM +0200, Adam Borowski wrote:
> > Many compressors do assign a meaning to level 0: either null compression or
> > the lowest possible level. This differs from our "unset thus default".
> > Thus, let's
On Sat, Oct 21, 2017 at 06:49:01PM +0200, Adam Borowski wrote:
> Many compressors do assign a meaning to level 0: either null compression or
> the lowest possible level. This differs from our "unset thus default".
> Thus, let's not unnecessarily confuse users.
I agree 'level 0' confusing,
On Mon, Oct 23, 2017 at 11:02:54PM -0600, Liu Bo wrote:
> It's pointless to defer it to a kthread helper as we're not under a
> special context.
>
> For reference, commit 1f78160ce1b1 ("Btrfs: using rcu lock in the
> reader side of devices list") introduced RCU freeing for device
> structures.
>
Hi,
I've had problems with a btrfs filesystem on a usb disk. I made a
successfull backup of all data and created the filesystem from scratch.
I'm not able to restore all backuped data because of a kernel oops.
The problem is reproducible.
I've checked my RAM alreayd with memtest86 for 8h
On 23.10.2017 23:57, Liu Bo wrote:
> Currently drop_caches is used to invalidate file's page cache so that
> buffered read can hit disk, but the problem is that it may also
> invalidate metadata's page cache, so the test case may not get read
> errors (and repair) if reading metadata has
On 2017年10月25日 14:54, Tom Hale wrote:
>
>
> On 19/10/17 15:58, Qu Wenruo wrote:
>> On 2017年10月19日 16:53, Tom Hale wrote:
>>> In running btrfs check, I got the following message:
>>>
>>> warning line 4144
>>>
>>> Could this be a little more descriptive?
>>>
>>> * Does it mean I should
On 19/10/17 15:58, Qu Wenruo wrote:
> On 2017年10月19日 16:53, Tom Hale wrote:
>> In running btrfs check, I got the following message:
>>
>> warning line 4144
>>
>> Could this be a little more descriptive?
>>
>> * Does it mean I should rebuild my FS from scratch?
>> * Is there anything I can do